Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-100

Text File | 1995-12-31 | 132KB | 3,390 lines

C.S.M.P. Digest             Sat, 10 Jun 95       Volume 3 : Issue 100

Today's Topics:

        Anyone doing lots of PPC assembly language?
        Can one do custom controls w-o CDEFs?
        Extracting data from AEDescs
        Getting rid of Option-
        How to disable Text Item ?
        To OOP or not to OOP. That...
        TransSkel 3.20 is available (CW 6 - SC++ 8)
        malloc vs. NewPtr
        newbie. How to get open file dialog box.



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroups
comp.sys.mac.programmer.help, csmp.tools and csmp.misc. It is designed for
people who read news semi-regularly and want an archive of the discussions.
If you don't know what a newsgroup is, you probably don't have access to
it. Ask your systems administrator(s) for details. If you don't have access
to news, you may still be able to post messages to the group by using a
mail server like anon.penet.fi (mail [e-mail] for more
information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (James Hague)
Subject: Anyone doing lots of PPC assembly language?
Date: 15 May 1995 01:20:52 GMT
Organization: Northwest Nexus, Inc. - Professional Internet Services

I know that you'd have to be an idiot to write lots of PPC assembly
(other than for code generators) and I know that Apple recommends against
it, but still:  Is anyone out there writing significant portions of an
app or game or whatever in PowerPC assembly?  I'd love to hear what you
have to say.

James Hague
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Mark W. Allender)
Date: 16 May 1995 20:27:29 GMT
Organization: Prairienet, the East-Central Illinois Free-Net

sandor ([e-mail]) wrote:

: What is needed is an (inline) PPC assembler from Metrowerks, asap.
                       ^^^^^^^^

This is *key*.  Not only for PPC and 68K as well.  I really dislike
having only function level asm available to me.

PC compilers have had inline asm for a while.  This is one area of mac
programming that needs to catch up.  (But I will say that CW's profiling
is really boss!)

--
-Mark Allender
-Parallax Software
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Patrik Johansson)
Date: Tue, 16 May 1995 22:01:24 +0200
Organization: KTH


>
> Only problem is the manuals. They do 64 bit implementations mixed
> in with 32 bit implementations and 64 bit running in '32 bit mode'.
> The notation can drive you crazy. But again, once you get the hang
> of it, it all makes sense.
>
> What is needed is an (inline) PPC assembler from Metrowerks, asap.

What is the best Reference book for PPC programming? Note, i am not looking
for a talkative tutorial with lots of pictures etc, a reference manual!

Pj

+++++++++++++++++++++++++++

>From [e-mail] (Lawson English)
Date: 16 May 1995 21:57:28 GMT
Organization: Primenet Services for the Internet [phone]

Mark W. Allender ([e-mail]) wrote:
: sandor ([e-mail]) wrote:

: : What is needed is an (inline) PPC assembler from Metrowerks, asap.
:                        ^^^^^^^^

: This is *key*.  Not only for PPC and 68K as well.  I really dislike
: having only function level asm available to me.

I don't see it as that big an issue. Sure, the Symantec in-line assembler
for 68K is nice (do they have one for PPC?), but with PPC code, I think
that I would PREFER to have function-level asm, as that way I don't have
to try and second-guess the compiler while its doing register-coloring
optimizations or somesuch.

I understand that CW 6 STILL doesn't have that PPC assembler?



--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (James Hague)
Date: 16 May 1995 19:50:48 GMT
Organization: Northwest Nexus, Inc. - Professional Internet Services

In article <3paej2$[e-mail]>,
>James Hague ([e-mail]) wrote:
>: I know that you'd have to be an idiot to write lots of PPC assembly
>
>I don't understand what the taboo is on doing PPC assembly.  Assembly code
>is assembly code in my book (aside from the obvious differences).

Heck, I don't have a problem with it.  In fact, I'd love to get my hands
on a decent PPC assembler so I could jump right in.  I've always found
assembly language programming to be fun.

My comments were mostly to calm the religious masses.  I've seen far too
many people get attacked for not bowing down to Apple.

Anyhow, what's available for doing PPC assembly?  MOPS and PowerMacForth
both have assemblers (MOPS is still a 68K system, though).  Codwarrior 6
was supposed to support it, but I haven't heard for sure.  The Fantasm
folk claim that v4 will generate PPC code, but that's likely a long way
off.  And there's the MPW assembler from Apple--ick.

James Hague
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Gabe Mares)
Date: Tue, 16 May 1995 17:21:11 -0600
Organization: University of Oklahoma

In article <[e-mail]>,
[e-mail] (sandor) wrote:

> What is needed is an (inline) PPC assembler from Metrowerks, asap.

Amen.  But not _only_ PPC.  We need 68K inline as well.  Something like
asm68K {...} and asmPPC {...}.

Gabe

+++++++++++++++++++++++++++

>From [e-mail] (Lawson English)
Date: 16 May 1995 23:41:20 GMT
Organization: Primenet Services for the Internet [phone]

James Hague ([e-mail]) wrote:
[snitpt]
: Anyhow, what's available for doing PPC assembly?  MOPS and PowerMacForth
: both have assemblers (MOPS is still a 68K system, though).  Codwarrior 6
: was supposed to support it, but I haven't heard for sure.  The Fantasm
: folk claim that v4 will generate PPC code, but that's likely a long way
: off.  And there's the MPW assembler from Apple--ick.


Word I have is that CW6 comes with PPCAsm in the MPW folder.

Ick indeed.

--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Lawson English)
Date: 16 May 1995 23:52:33 GMT
Organization: Primenet Services for the Internet [phone]

Patrik Johansson ([e-mail]) wrote:

: >
: > Only problem is the manuals. They do 64 bit implementations mixed
: > in with 32 bit implementations and 64 bit running in '32 bit mode'.
: > The notation can drive you crazy. But again, once you get the hang
: > of it, it all makes sense.
: >
: > What is needed is an (inline) PPC assembler from Metrowerks, asap.

: What is the best Reference book for PPC programming? Note, i am not looking
: for a talkative tutorial with lots of pictures etc, a reference manual!

 _Optimizing PowerPC Code_ by Gary Kacmarcik is currently the only book
available. I've heard that there is a *compiler* book for PowerPC coming
soon.

You also have the 601/604/6xx User's Manuals from IBM and Motorola.



 --
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Mark W. Allender)
Date: 17 May 1995 00:32:59 GMT
Organization: Prairienet, the East-Central Illinois Free-Net

Lawson English ([e-mail]) wrote:
: James Hague ([e-mail]) wrote:
: : off.  And there's the MPW assembler from Apple--ick.

: Ick indeed.

Not to sound naive (it is possible), but what is wrong with that assembler?
It works fine for me.

--
-Mark Allender
-Parallax Software
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Lawson English)
Date: 17 May 1995 01:20:17 GMT
Organization: Primenet Services for the Internet [phone]

Mark W. Allender ([e-mail]) wrote:
: Lawson English ([e-mail]) wrote:
: : James Hague ([e-mail]) wrote:
: : : off.  And there's the MPW assembler from Apple--ick.

: : Ick indeed.

: Not to sound naive (it is possible), but what is wrong with that assembler?
: It works fine for me.

Indeed it does. HOwever, it is really difficult to learn to use, IMHO,
and 1) requires that you have MPW and 2) that you know how to use MPW.

The documentation is "spotty" shall we say?



--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Lawson English)
Date: 17 May 1995 03:26:17 GMT
Organization: Primenet Services for the Internet [phone]

sandor ([e-mail]) wrote:

: > I don't understand what the taboo is on doing PPC assembly.  Assembly code
: > is assembly code in my book (aside from the obvious differences).

: Agreed !  In fact PPC assembly was a lot easier to learn and use
: that 68K (let alone x86). It is a bit strange at first because of
: being a load store architecture. But once over that it goes smoothly.


How are you at scheduling so that the pipelines remain full? What about
604 vs 601 optimization?


--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (david matiskella)
Date: 17 May 1995 04:02:18 GMT
Organization: University of Notre Dame

In article <3pbqcp$[e-mail]>, [e-mail] (Lawson English) writes:
|> sandor ([e-mail]) wrote:
|>
|> : > I don't understand what the taboo is on doing PPC assembly.  Assembly code
|> : > is assembly code in my book (aside from the obvious differences).
|>
|> : Agreed !  In fact PPC assembly was a lot easier to learn and use
|> : that 68K (let alone x86). It is a bit strange at first because of
|> : being a load store architecture. But once over that it goes smoothly.
|>
|>
|> How are you at scheduling so that the pipelines remain full? What about
|> 604 vs 601 optimization?
|>
|>
|> --
|> -------------------------------------------------------------------------------
|> Lawson English                            __  __     ____  ___       ___ ____
|> [e-mail]                     /__)/__) / / / / /_  /\  / /_    /
|>                                         /   / \  / / / / /__ /  \/ /___  /
|> -------------------------------------------------------------------------------
I assume he doing it by hand.  For 601/603/604 optimization you
have to either pick one or pick the code which gives acceptable
performance on all three. Nothing new. Optimum pentium code isn't
optimum 486 code. Similiar Optium 68K is not the same as otptium
68040 code. It's not some new problem. Personally I would
optimize for the 601 since A) you can buy a system that uses
it, B) it's most likely going to be the slowest of the 3.

+++++++++++++++++++++++++++

>From [e-mail] (The Weasel)
Date: 17 May 1995 06:36:23 GMT
Organization: Computer Science Department, Stanford University, CA USA.

In article <3pbj0h$[e-mail]>,
Lawson English <[e-mail]> wrote:
> The documentation is "spotty" shall we say?

Huh? I found the documentation to be fine. At least it was all in one
place as opposed to the rest of the mpw docs. One thing that made me
grumpy though was that it was basically the ibm assembler rather than
following the lead of the previous 68k mpw assemblers with directives
like while etc.

This is, of course, all my own opinion.

Peter
--
ObURL:       <a href="http://xenon.stanford.edu/~pchang/bhh.html">
ObQuote:     Chi non ha paura di morire muore una volta sola.
                                -- Giovanni Falcone


+++++++++++++++++++++++++++

>From [e-mail] (sandor)
Date: Wed, 17 May 1995 08:03:27 -0800
Organization: CRL Dialup Internet Access

In article <3pbqcp$[e-mail]>, [e-mail] (Lawson
English) wrote:

> How are you at scheduling so that the pipelines remain full? What about
> 604 vs 601 optimization?

The IBM/Motorola manuals (e.g. PowerPC 604 RISC Microprocessor User's
Manual) contain detailed examples of how the pipeline works. They also
have info on how to schedule your code (see for example section 6.6 in
the 604 User's manual). There is nothing obscure or tricky about it.
>From what I can tell, it is mostly common sense once you see how the
pipelines work -- although I'm sure that experience helps. I also go
through the CW compiler output and also look in ROM to see what IBM
and Apple do. Would appreciate seeing more informative examples posted
here by the experts (e.g. last year Tim Olson at Apple Computer/Somerset
posted several interesting code examples).

There are some differences between the 601 and 604 but they don't seem
to be a major matter. What I have done is concentrate on the 604 (there
are none of the old POWER ops to tempt one, e.g. when a 64 bit divide is
needed). And the manual is more readable. In fact the 604 (on paper) looks
like a really great chip -- with its 3 integer pipelines, etc.

But at present don't have a 604 to program ! Am waiting patiently. Believe
that one facility it has, that the 601 doesn't, is a "nanosecond" timer
(used via the mftb op). Am I correct about this ? If so, this could help
with checking how well ones code is doing. Does anyone know about this ?
I found the manuals rather inconclusive.

Nick Burgoyne           <[e-mail]>            17 May 1995

+++++++++++++++++++++++++++

>From [e-mail] (Lawson English)
Date: 17 May 1995 16:37:47 GMT
Organization: Primenet Services for the Internet [phone]

Mark W. Allender ([e-mail]) wrote:
: James Hague ([e-mail]) wrote:
: : I know that you'd have to be an idiot to write lots of PPC assembly

: Why?

: : (other than for code generators) and I know that Apple recommends against
: : it, but still:  Is anyone out there writing significant portions of an
: : app or game or whatever in PowerPC assembly?  I'd love to hear what you
: : have to say.

: Apple recommends against a lot of things -- and I mostly ignore those
: things that I believe that I should.  With that said:

Actually, Apple recommends that you code it in C that is optimized for
algorithms and data structures first and benchmark that to see where you
need to go to assembler. And once you've gone to assembler, make sure
that it really IS faster than C that has been optimized for algorithms
and data structures.

They dont' recommend that you not use assembler -only that you be sure
that assembler is actually faster.

: Parallax will probably be doing quite a bit of PPC assembly for Descent.
: We have to.  Otherwise, frame rate will be _slow_ -- and I mean really
: slow, compared to what it could be.

Yer a better man than I, Gunga Din... Or are you worried about CopyBits
issues?

: I don't understand what the taboo is on doing PPC assembly.  Assembly code
: is assembly code in my book (aside from the obvious differences).


Folks are lazy, mostly, and RISC CPUs are designed to make compilers
efficient, so why bother when you don't have to?

If you have to, you have to.

What bottle-necks are you finding where assembler is that far superior to
C, BTW?

--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (James Hague)
Date: 17 May 1995 16:28:21 GMT
Organization: Northwest Nexus, Inc. - Professional Internet Services

Mark W. Allender <[e-mail]> wrote:
>: : off.  And there's the MPW assembler from Apple--ick.
>
>: Ick indeed.
>
>Not to sound naive (it is possible), but what is wrong with that assembler?
>It works fine for me.

Possibly nothing.  Except that you have to buy and use MPW in order to
get it.

James Hague
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Kevin Warne)
Date: 17 May 1995 16:20:55 GMT
Organization: Reflective Software

In article <3pb748$[e-mail]>, [e-mail] (Lawson English) says:
>I don't see it as that big an issue. Sure, the Symantec in-line assembler
>for 68K is nice (do they have one for PPC?), but with PPC code, I think
>that I would PREFER to have function-level asm, as that way I don't have
>to try and second-guess the compiler while its doing register-coloring
>optimizations or somesuch.

Watcom C++ (for x86) has great support for this sort of thing.  You
specify the registers/memory that you read/write in your inline assembly
and you specify calling conventions in terms of register setup/return
(so it's even type-safe!) and their optimizer will generate code to
match.  Pity that more compilers don't support this level of inline
assembly...

Regards,
Kevin

____
Kevin Warne / [e-mail] / DDD [phone] / FAX [phone]
Reflective Software Corporation
2660 Estevan Ave, Victoria, BC, CANADA  V8R 2T4
Warne's Garbage Collector (WGC) = Fastest C++ heap manager, email for demo app

+++++++++++++++++++++++++++

>From [e-mail] (Philip Machanick)
Date: 18 May 1995 06:44:34 GMT
Organization: Computer Science Dept, Wits University

In article <3pd875$[e-mail]>, [e-mail]
(James Hague) wrote:

>>Possibly nothing.  Except that you have to buy and use MPW in order to
>get it.

Or CW6 from what I hear -- though it probably still runs in MPW.
--
Philip Machanick
Computer Science Department, University of the Witwatersrand
2050 Wits, South Africa
[e-mail]  27(11)716-3309 fax [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 18 May 1995 18:03:44 GMT
Organization: Helsinki University of Technology

In article <3paej2$[e-mail]> [e-mail] (Mark W. Allender) writes:
>James Hague ([e-mail]) wrote:
>: I know that you'd have to be an idiot to write lots of PPC assembly
>
>Parallax will probably be doing quite a bit of PPC assembly for Descent.
>We have to.  Otherwise, frame rate will be _slow_ -- and I mean really
>slow, compared to what it could be.
>
>I don't understand what the taboo is on doing PPC assembly.  Assembly code
>is assembly code in my book (aside from the obvious differences).

I agree quite totally. If a person wants to use assembly language, then
he/she should be allowed to use it. At least MWC doesn't seem to be able
to generate very fast code for the PPC... I tried contacting [e-mail]
about his assembler, but he hasn't replied. I guess I could use PPCAsm,
since I have access to ETO disks, but I'm not very enthusiastic about
touching MPW.

I still think that MetroWorks C or Symantec C should provide inline
PPC and 68020 assembly (MWC only does plain 68K). If you compare the
task of writing a C compiler and that of writing an assembler, the
assembler seems trivial in comparison. I just want to be able to
access my C structures and variables from assembly, so an inline
assembler (like the one in Think C) is the ideal solution.

On the 68K, my C versions are about twice as slow as the optimized
assembly language. On the PowerPC things are slightly better because
it has more registers, but I still see a lot of room for improvement.

--
Juri Munkki [e-mail]      There ain't no such thing as a shareware lunch.
http://www.hut.fi/~jmunkki              Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Phil Shapiro)
Date: Thu, 18 May 1995 16:38:21 -0400
Organization: Symantec Corp.

In article <3pd875$[e-mail]>, [e-mail]
(James Hague) wrote:

| Mark W. Allender <[e-mail]> wrote:
| >: : off.  And there's the MPW assembler from Apple--ick.
| >
| >: Ick indeed.
| >
| >Not to sound naive (it is possible), but what is wrong with that assembler?
| >It works fine for me.
|
| Possibly nothing.  Except that you have to buy and use MPW in order to
| get it.

Actually, the SDA #3 CD includes a pre-release copy of an SPM integrated
version of Apple's PPCAsm assembler. It's a drop-in translator for the 8.0
SPM.

   -phil

+++++++++++++++++++++++++++

>From Heiner Wolf <[e-mail]>
Date: 18 May 1995 16:02:40 GMT
Organization: University of Ulm, Germany

> I know that you'd have to be an idiot to write lots of PPC assembly
> (other than for code generators) and I know that Apple recommends against
> it, but still:  Is anyone out there writing significant portions of an
> app or game or whatever in PowerPC assembly?  I'd love to hear what you
> have to say.

We are coding the kernal of a JPEG image decompressor in assembler.

Yes, I know. The compilers are so good and it is not neccessary. But if I can
spare a single instruction per color component per pixel at 20 320x240 frames
per second then its worth the effort.

--
Klaus H.Wolf
ethernet: 08:00:20:12:2a:01
internet: [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Robert Cassidy)
Date: Thu, 18 May 1995 16:53:33 -0700
Organization: UC Irvine

In article <3pg260$[e-mail]>, [e-mail] (Juri
Munkki) wrote:

> In article <3paej2$[e-mail]> [e-mail] (Mark
W. Allender) writes:

> >I don't understand what the taboo is on doing PPC assembly.  Assembly code
> >is assembly code in my book (aside from the obvious differences).

> I agree quite totally. If a person wants to use assembly language, then
> he/she should be allowed to use it. At least MWC doesn't seem to be able
> to generate very fast code for the PPC... I tried contacting [e-mail]
> about his assembler, but he hasn't replied. I guess I could use PPCAsm,
> since I have access to ETO disks, but I'm not very enthusiastic about
> touching MPW.

I don't think that PPC assembly it totally taboo - just that there are
strong warnings in place that it is a lot harder to improve over the
compiler. There are lots of hard-core assembly programmers that swear up
and down that assembly is the *only* way to go - C is for wusses. These
people, for a large project, will probably not gain significantly (if at
all) over the programmer that starts in C and optimizes little areas in
assembly. They might have gotten away with it on an 040 or 486, but I
think a PPC would break them.

The other problem is that I believe the differences between the 601, 603,
604, 620, etc. are significant enough that all of those extra hours put
into the assembly might be wasted once you run on the next chip - the
compiler (assuming that it's been updated) should be smart enough to
either 1) tailor your code easily to the chip or 2) avoid doing anything
truly criminal to any one chip - sort of the lesser of all evils approach.

--
Bob Cassidy
UC Irvine

+++++++++++++++++++++++++++

>From [e-mail] (Mark W. Allender)
Date: 19 May 1995 13:16:01 GMT
Organization: Prairienet, the East-Central Illinois Free-Net

Robert Cassidy ([e-mail]) wrote:

: I don't think that PPC assembly it totally taboo - just that there are
: strong warnings in place that it is a lot harder to improve over the
: compiler. There are lots of hard-core assembly programmers that swear up

This argument over asm vs. C has been around for a long time.  Compilers
for the PC generate really great code (watcom in particular).  But you know
what, hand optimizing in asm in the most crucial spots can *always* be a
win.  Why?  Because *you* know about the structure of your program, and how
you can treat register allocation.  You may not always get a great speedup
over the compiler, but in most cases, I believe that it is worth the effort
(if you choose your battles carefully).

I have yet to see MWC generate the best code possible for my leaf routines
-- and those are the ones that are getting called 10's of thousands of
times per frame.

I have achieved a 20-30% speedup just by rewriting around 10 crucial
routines in asm.  The point -- if you care about speed, then you should
know how to optimize properly in asm!

--
-Mark Allender
-Parallax Software
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Robert Cassidy)
Date: Fri, 19 May 1995 10:50:00 -0700
Organization: UC Irvine

In article <3pi5mh$[e-mail]>, [e-mail] (Mark
W. Allender) wrote:

> You may not always get a great speedup
> over the compiler, but in most cases, I believe that it is worth the effort
> (if you choose your battles carefully).
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*That's* why the warning is there.

--
Bob Cassidy
UC Irvine

+++++++++++++++++++++++++++

>From Edmond Underwood <[e-mail]>
Date: 20 May 1995 00:31:13 GMT
Organization: Rocky Mountain Internet Inc.

>The IBM/Motorola manuals (e.g. PowerPC 604 RISC Microprocessor User's
>Manual) contain detailed examples of how the pipeline works. They also
>have info on how to schedule your code (see for example section 6.6 in
>the 604 User's manual). There is nothing obscure or tricky about it.
>From what I can tell, it is mostly common sense once you see how the
>pipelines work -- although I'm sure that experience helps. I also go
>through the CW compiler output and also look in ROM to see what IBM
>and Apple do. Would appreciate seeing more informative examples posted
>here by the experts (e.g. last year Tim Olson at Apple Computer/Somerset
>posted several interesting code examples).

>There are some differences between the 601 and 604 but they don't seem
>to be a major matter. What I have done is concentrate on the 604 (there
>are none of the old POWER ops to tempt one, e.g. when a 64 bit divide is
>needed). And the manual is more readable. In fact the 604 (on paper) looks
>like a really great chip -- with its 3 integer pipelines, etc.
>
>But at present don't have a 604 to program ! Am waiting patiently. Believe
>that one facility it has, that the 601 doesn't, is a "nanosecond" timer
>(used via the mftb op). Am I correct about this ? If so, this could help
>with checking how well ones code is doing. Does anyone know about this ?
>I found the manuals rather inconclusive.

>Nick Burgoyne           <[e-mail]>            17 May 1995

Where can one find this book on 604 assembly?  What assembler do they
recommend.  Just a standard CC on AIX or what?  Which brings me to my
next question.  Who is shipping a 604, and what is it running?  NT won't
be running on it until early to mid July.  What about AIX?

-thanks

- -------------------------------------------------------------------------------

Edmond Underwood
Systems Management Group
Computing & Network Services (University of Colorado)
E-mail:  [e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 20 May 1995 11:07:10 GMT
Organization: Helsinki University of Technology

In article <3pbqcp$[e-mail]> [e-mail] (Lawson English) writes:
>sandor ([e-mail]) wrote:
>
>: > I don't understand what the taboo is on doing PPC assembly.  Assembly code
>: > is assembly code in my book (aside from the obvious differences).
>
>: Agreed !  In fact PPC assembly was a lot easier to learn and use
>: that 68K (let alone x86). It is a bit strange at first because of
>: being a load store architecture. But once over that it goes smoothly.
>
>
>How are you at scheduling so that the pipelines remain full? What about
>604 vs 601 optimization?

I don't see any reason why PPC assemblers couldn't be made smart about
this and allowed to optimize the code by reordering instructions whenever
possible. It would also be neat to have an interactive tool that would
show instruction timings and pipelines states as you edit the assembly
source code.

--
Juri Munkki [e-mail]      There ain't no such thing as a shareware lunch.
http://www.hut.fi/~jmunkki              Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 20 May 1995 11:10:35 GMT
Organization: Helsinki University of Technology

In article <3pbsga$[e-mail]> [e-mail] (david matiskella) writes:
>68040 code. It's not some new problem. Personally I would
>optimize for the 601 since A) you can buy a system that uses
>it, B) it's most likely going to be the slowest of the 3.

My experience tells me that the 5200LC is the slowest PowerMac. It
has a 75Mhz 603. The problem seems to be that it has a narrow data
bus.

--
Juri Munkki [e-mail]      There ain't no such thing as a shareware lunch.
http://www.hut.fi/~jmunkki              Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Mark W. Allender)
Date: 20 May 1995 13:02:32 GMT
Organization: Prairienet, the East-Central Illinois Free-Net

Robert Cassidy ([e-mail]) wrote:
: > (if you choose your battles carefully).
: *That's* why the warning is there.

That warning should be there for any optimization of asm.  Not just PPC.

--
-Mark Allender
-Parallax Software
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Kieran L. Brown)
Date: 20 May 1995 16:16:14 +0100
Organization: KGS

In message <3pkigu$[e-mail]> Juri Munkki wrote:

> In article <3pbqcp$[e-mail]> [e-mail] (Lawson English) writes:
> >sandor ([e-mail]) wrote:
> >
> >: > I don't understand what the taboo is on doing PPC assembly.  Assembly code
> >: > is assembly code in my book (aside from the obvious differences).
> >
> >: Agreed !  In fact PPC assembly was a lot easier to learn and use
> >: that 68K (let alone x86).

Of course it is! It is RISC, after all!

If you really want a good processor, take a look at the new generation of ARM
processors. They range from cheap and fast to less cheap and blindingly fast.
They kick the PowerPC into a cocked hat!

--
Kieran L. Brown
KGS Solutions Limited
... 'Bother', said Pooh, glowing in the dark.

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 20 May 1995 21:46:41 GMT
Organization: Helsinki University of Technology

In article <[e-mail]> [e-mail] (Robert Cassidy) writes:
>I don't think that PPC assembly it totally taboo - just that there are
>strong warnings in place that it is a lot harder to improve over the
>compiler. There are lots of hard-core assembly programmers that swear up
>and down that assembly is the *only* way to go - C is for wusses. These
>people, for a large project, will probably not gain significantly (if at
>all) over the programmer that starts in C and optimizes little areas in
>assembly. They might have gotten away with it on an 040 or 486, but I
>think a PPC would break them.

This is exactly the reason why PPCAsm is a bad idea and inline assembly
for MWC or Symantec C is a good idea. If you are forced to work with a
separate assembly tool, you are more likely to write assembly code than
you would if you started out with a C program.

I'm usually pretty good at detecting the critical parts of a program
(those few % that execute all the time) and sometimes code these parts
directly in assembly language, if the problem is easier to express in
assembly language. My normal way of working is to prototype in C, then
decide which way is easier (asm or C) and implement one.

I prefer the true inline approach to the asm function approach (Think C
vs. MWC) because the truely inlined approach allows you to set up
variables with C and then use asm only for the critical part of that
function whereas in an asm function you either have to set up everything
with asm or you have to define a calling C function that does the
setting up.


Everyone knows that underlined text is bad and should never be used for
anything and that it was only invented because typewriters couldn't
easily type italic or boldface. Yet word processsors all allow you to
use underlined text. I wish compiler writers would listen to the users
and allow inline assembly even though they know that is not officially
a good idea to use assembly language.

--
Juri Munkki [e-mail]      There ain't no such thing as a shareware lunch.
http://www.hut.fi/~jmunkki              Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Maynard James Handley)
Date: 21 May 1995 09:17:20 GMT
Organization: University of Otago, Dunedin, NZ


> : : : off.  And there's the MPW assembler from Apple--ick.

> : : Ick indeed.

> : Not to sound naive (it is possible), but what is wrong with that assembler?
> : It works fine for me.

> Indeed it does. HOwever, it is really difficult to learn to use, IMHO,
> and 1) requires that you have MPW and 2) that you know how to use MPW.

> The documentation is "spotty" shall we say?

It is certainly true that the PPCAsm documentation sucks. I have no idea
how anyone is supposed to produce their first code without an example to
guide them.
However it is NOT true that PPAsm requires MPW. SC++ 8 (and anything else
that uses Toolserver) can make use of PPCAsm.
I hav patched together an AppleScript plus a Toolserver script that
compiles my C/C++ in the Symantec environment, and the assembly and linking
under Toolserver. Works like a charm.
(And might I say, shows just how cool AppleScript is. The scripts were
put together using recording, and do all sortsa extra stuff like
shuffle files around and auto launch apps.)

I'd recommend anyone interested in PPC assembly and with the SC++8 CD to
look at PPCAsm and Toolserver.

I'm afraid I don't know about MW. Can they use Toolserver and produce
xcoff objects so they can be linked by PPCLink?

Maynard Handley

+++++++++++++++++++++++++++

>From [e-mail] (Maynard James Handley)
Date: 21 May 1995 09:34:18 GMT
Organization: University of Otago, Dunedin, NZ

Hi,
Enough about whether or not to code in PPC assembly.
a) It's not amazingly hard---common sense and understanding how the chip
works will tell you most all you need to know about keeping the pipelines
busy.
b) Have the people on the side of the compilers actually LOOKED at
compiler output? I've only looked at SC and MW, not xlc and the new Motorola
compilers which may be much better. But SC and MW are way suboptimal.
Common reasons for this are
  * Compiling is tough. The code goes through a bunch of abstractions
  and data is lost on the way to the code generator. You in assembly know
  that lost info.
  * Sometimes in C you can't specify what you want done exactly---like
  load in a value from somewhere as a double then do a bunch of single
  precision ops on it, then write it as a double. The compiler will
  insert various steps along the way that do roundings and such you
  probably don't need. The same thing if you do a lot of work mixing
  signed and unsigned values.
  * There are some very cools PPC features you simply accnot access from
  C. Examples are
    # Clearing an array to zero by using the cache block clearing operations.
    # Touching cache data a few operations before you need it so as
    to preload it.
    # Those funky shift and exatract with mask operations for bit-field
    extraction.
  * There are common-sense optimizations for speeding up code like
  software-pipelining to interleave loads/stores for the next/previous
  set of data while doing arithmetic on the current set. The compilers should
  be capable of this sort of thing, like loop-unrolling, but doesn't seem
  to be.

Having said that, a change of pace and a real question, not faffing around.

I am trying to get to grips with the nitty-gritty of PPC 601 timings and
have come across something that does not make sense to me. I'd appreciate
any comments people have.
Essentiallu what I am trying to figure out is why a floating
point store, fpsb, seems to block a subsequent integer store by two clocks.
Consider the code

        stfd fp0, 0(r3)
        lwz  r4, 0(r5)
        addi r0, r0, 0
        addi r0, r0, 0
        addi r0, r0, 0
                                                (Example 1)
        addi r0, r0, 0
        addi r0, r0, 0
        addi r0, r0, 0
        addi r0, r0, 0

 blr
 END

This executes in exactly the time one would expect, one clock per
instruction with the blr basically free. The long string of addis
before the blr is to make sure we have CARB/CACC free enough
in advance for the blr. This simplifies the problem so we don't have
to deal with two issues at once.
(If you don't appreciate the point of that, you're probably not going to be
able to answer the question.)
In the same vein, everything is set up not to cross double-word boundaries.

Now suppose we change this code to

        stfd fp0, 0(r3)
        stw  r4, 0(r5)
        addi r0, r0, 0
        addi r0, r0, 0
        addi r0, r0, 0
                                                (Example 2)
        addi r0, r0, 0
        addi r0, r0, 0
        addi r0, r0, 0
        addi r0, r0, 0

 blr
 END

Now the code will take two cycles longe. But the two extra cycles are stalls
behind the stfd. We can see this if we change the code to

        stfd fp0, 0(r3)
        addi r0, r0, 0
        addi r0, r0, 0
        stw  r4, 0(r5)
        addi r0, r0, 0
                                                (Example 3)
        addi r0, r0, 0
        addi r0, r0, 0
        addi r0, r0, 0
        addi r0, r0, 0

 blr
 END
This code executes in the same amount of time as the first snippet of code.

Now reading the 601 manual, chapter 7 closely, it's not at all clear why
this should happen. What do we know?
The fp store will pass through ID, IE and IC all in one cycle. This
is confirmed by the fact that in example (1) there are no stalls.
the fp store WILL block for three clocks in FPSB while the data is hauled
through the fp pipeline but that should not affect anyone. Additionally
it is only after these three clocks that CARB and CACC are needed,
while (in example 2) the integer store would need them earlier thus there
would be no structural hazard regarding those. Claerly from the code there is
no data hazard.

My hypothesis is that while the 601 manual seems to imply FPSB and ISB (pg 7-36)
are independent, they are in fact not independent. Thus with FPSB occupied
there is a structural hazard that prevents ISB from being available for use.
Until FPSB is freed, any instruction that wants to access ISB is frozen.

Is this in fact correct, or is there a better explanation for this fact?

I came across this while playing around trying to write opmtimal code
for setting a long array to the same (non-zero) value. This is an extremely
interesting problem. One would like to use stfd and write 8 bytes at a time
but that is not the full answer because stfd sits in FPSB for three clocks.
A long sequence of stw's is not a great idea because more than four in a
row and you starve the instruction queue (really makes you wish 601 had
Harvard caches). My solution uses an insane mix of stfd's interleaved with
stswi's with gaps between these to do various weird stuff. It looks
absurd but is wicked-fast.

Has anyone made code available that is known to be optimal for this sort of
problem? If not, might I suggest that we formalize it as a contest? Writing
this sort of code is wonderful fun and even though one reaches a point
where saving one cycle in 200 doesn't make sense as an engineering issue,
as a contest no work is too much to achieve optimal results.
If enough people agree this might be fun, I can formalize the problem
and post it.

(Finally please no-one give me the lecture on stswi being bad for machines
other than 601. I know, I know. This stuff is all shared-library based. I'll
just rewrite the code and use a new lib for 603 and 604.)

Maynard Handley


+++++++++++++++++++++++++++

>From [e-mail] (Lawson English)
Date: 21 May 1995 21:04:42 GMT
Organization: Primenet Services for the Internet [phone]

Maynard James Handley ([e-mail]) wrote:
[snipt]
: Having said that, a change of pace and a real question, not faffing around.

: I am trying to get to grips with the nitty-gritty of PPC 601 timings and
: have come across something that does not make sense to me. I'd appreciate
: any comments people have.
: Essentiallu what I am trying to figure out is why a floating
: point store, fpsb, seems to block a subsequent integer store by two clocks.
: Consider the code

You missed it. From page i-175 of the Motorola PowerPC 601 User's Manual:

"For a series of fp store instructions, the maximum throughput is one fp
store every three processor cycles. Each store holds in FWA for 2 cycles
and this freezes the entire PFU pipeline. THerefore, one cannot schedule
fp instructions in between the float stores to improve throughput in the
fp unit. Becuase the float stores also take ua a position in the integer
pipeline, there is no opportunity to schedule in integer instructions and
improve throughput in the interger pipeline."

It goes on to say that FP load/store operations are inherently slower
than FP load/stores, if youare doing a block-move/copybits style function.


The only exception to this, BTW, is if you are writing to non-cacheable
memory, like the VRAM, where the latency of the memory is such that you
have more delay from accessing memory than from freezing the pipelines
for a few cycles.

The 604 may be different in this respect (faster at fp stores, I believe).

--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Sun, 21 May 1995 14:49:45 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <3pi5mh$[e-mail]>, [e-mail] (Mark
W. Allender) wrote:
> This argument over asm vs. C has been around for a long time.  Compilers
> for the PC generate really great code (watcom in particular).  But you know
> what, hand optimizing in asm in the most crucial spots can *always* be a
> win.  Why?  Because *you* know about the structure of your program, and how
> you can treat register allocation.  You may not always get a great speedup
> over the compiler, but in most cases, I believe that it is worth the effort
> (if you choose your battles carefully).

True. There are exceptions though, such as pipeline optimization (a must
with most RISC architectures) that a smart linker could do, a smart person
could also learn this after a couple of months/years, but for the average
code cruncher it's better to stick to tools.

--Kent

--
Kent Sandvik   [e-mail]                  Working with Multimedia stuff...
Apple Developer Technical Support.                 Private activities on Internet.

+++++++++++++++++++++++++++

>From Mark Williams <[e-mail]>
Date: 22 May 1995 07:47:49 +0100
Organization: Streetly Software


In article <3pfr30$[e-mail]>, Heiner Wolf writes:

>
> > I know that you'd have to be an idiot to write lots of PPC assembly
> > (other than for code generators) and I know that Apple recommends against
> > it, but still:  Is anyone out there writing significant portions of an
> > app or game or whatever in PowerPC assembly?  I'd love to hear what you
> > have to say.
>
> We are coding the kernal of a JPEG image decompressor in assembler.
>
> Yes, I know. The compilers are so good and it is not neccessary. But if I can

Falls down laughing. Just which compilers would those be...?

Mark Williams

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Mon, 22 May 1995 17:35:45 +1200 (NZDT)
Organization: (none)

[e-mail] (Maynard James Handley) writes:
> I am trying to get to grips with the nitty-gritty of PPC 601 timings and
> have come across something that does not make sense to me. I'd appreciate
> any comments people have.
> Essentiallu what I am trying to figure out is why a floating
> point store, fpsb, seems to block a subsequent integer store by two clocks.

The 601 manual talks about this on page I-175.  Each FP store holds in FWA
for two cycles, blocking both the FP and integer pipes.  Bummer.  This
makes it faster to move operations using integer loads and stores.  (if
the memory is cachable)

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Tim Olson)
Date: 20 May 1995 09:50:23 -0500
Organization: Apple/IBM/Motorola Somerset Design Center, Austin, TX

In article <3pbsga$[e-mail]>,
david matiskella <[e-mail]> wrote:
>I assume he doing it by hand.  For 601/603/604 optimization you
>have to either pick one or pick the code which gives acceptable
>performance on all three. Nothing new. Optimum pentium code isn't
>optimum 486 code. Similiar Optium 68K is not the same as otptium
>68040 code. It's not some new problem. Personally I would
>optimize for the 601 since A) you can buy a system that uses
>it, B) it's most likely going to be the slowest of the 3.

Actually, it is better to schedule code with the most parallel
microarchitecture in mind.  Since the 601 has a single, combined
integer/load/store unit, it really doesn't matter what order instructions
are fed through it, as long as the code is scheduled around true
dependencies (mainly loads to load-uses).

However, a 604 can benefit from having parallelism exposed.


--
        Tim Olson
        Apple Computer / Somerset
        ([e-mail])

+++++++++++++++++++++++++++

>From [e-mail] (Tim Olson)
Date: 20 May 1995 09:57:29 -0500
Organization: Apple/IBM/Motorola Somerset Design Center, Austin, TX

In article <[e-mail]>,
sandor <[e-mail]> wrote:
>But at present don't have a 604 to program ! Am waiting patiently. Believe
>that one facility it has, that the 601 doesn't, is a "nanosecond" timer
>(used via the mftb op). Am I correct about this ? If so, this could help
>with checking how well ones code is doing. Does anyone know about this ?
>I found the manuals rather inconclusive.

Yes, the PowerPC architecture has a 64-bit Timebase register which is
accessible in user-mode code.  What this register counts is implementation-
defined, but on all existing PowerPC processors (except 601, which does
not have the Timebase register, but instead has the RTC) the Timebase
counts multiples of bus clocks (i.e. the timebase increments every 4 bus
clocks).

The MFTB instruction returns the lower 32 bits of the timebase, while the
MFTBU instruction returns the upper.  It is left as an excercise to the
reader to come up with a short instruction sequence that returns a
"coherent" 64-bit pair, as the split read is not atomic...

--
        Tim Olson
        Apple Computer / Somerset
        ([e-mail])

+++++++++++++++++++++++++++

>From [e-mail] (Andrew Edgecombe)
Date: 19 May 1995 14:38:29 +1000
Organization: Department of Electronic Engineering, La Trobe University

Power mac forth? Where, when , who etc.
Someone please let me know about it!!!

[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Dom)
Date: Mon, 22 May 1995 12:28:50
Organization: i-cubed ltd., Cambridge, UK

In article <[e-mail]> [e-mail] (Robert Cassidy) writes:

>> >I don't understand what the taboo is on doing PPC assembly.  Assembly code
>> >is assembly code in my book (aside from the obvious differences).


>> I agree quite totally. If a person wants to use assembly language, then
>> he/she should be allowed to use it. At least MWC doesn't seem to be able
>> to generate very fast code for the PPC... I tried contacting [e-mail]
>> about his assembler, but he hasn't replied. I guess I could use PPCAsm,
>> since I have access to ETO disks, but I'm not very enthusiastic about
>> touching MPW.

>I don't think that PPC assembly it totally taboo - just that there are
>strong warnings in place that it is a lot harder to improve over the
>compiler. There are lots of hard-core assembly programmers that swear up
>and down that assembly is the *only* way to go - C is for wusses. These

These people also get up at six, have a cold shower, run barefoot for three
miles, before mowing the lawn with a pair of scissors.  And that's a Sunday
morning lie-in :)

Anyway, I'm doing some 403GA test code, and I have to use assembler.
Doesn't take too long to get your head around it, after which,
it's much like anything else.

--
 Dom - the look and feel of this sig is mine mine mine


+++++++++++++++++++++++++++

>From [e-mail] (Bradley S. Pliner)
Date: Tue, 23 May 1995 00:12:58 -0400
Organization: Drexel University

I strongly recommend staying away from RISC-based assembly programming,
unless it's 100% necessary, and you've eaten your weeties. You have a lot
to worry about that is not an issue with CISC-based assembly. Foremost,
pipelined instructions will be a real pain in the butt to work with.

In article <[e-mail]>, [e-mail]
(Dom) wrote:

> In article <[e-mail]>
[e-mail] (Robert Cassidy) writes:
>
> >> >I don't understand what the taboo is on doing PPC assembly.  Assembly code
> >> >is assembly code in my book (aside from the obvious differences).
>
>
> >> I agree quite totally. If a person wants to use assembly language, then
> >> he/she should be allowed to use it. At least MWC doesn't seem to be able
> >> to generate very fast code for the PPC... I tried contacting [e-mail]
> >> about his assembler, but he hasn't replied. I guess I could use PPCAsm,
> >> since I have access to ETO disks, but I'm not very enthusiastic about
> >> touching MPW.
>
> >I don't think that PPC assembly it totally taboo - just that there are
> >strong warnings in place that it is a lot harder to improve over the
> >compiler. There are lots of hard-core assembly programmers that swear up
> >and down that assembly is the *only* way to go - C is for wusses. These
>
> These people also get up at six, have a cold shower, run barefoot for three
> miles, before mowing the lawn with a pair of scissors.  And that's a Sunday
> morning lie-in :)
>
> Anyway, I'm doing some 403GA test code, and I have to use assembler.
> Doesn't take too long to get your head around it, after which,
> it's much like anything else.
>
> --
>  Dom - the look and feel of this sig is mine mine mine

-=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=-
Bradley S. Pliner,  [e-mail],  [phone] (Call 24 hr/day)
Drexel University: Comp Sci BS (Sept '95), Software Engineering MS (June '96)
-=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=-

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Wed, 24 May 1995 13:59:21 +1200 (NZDT)
Organization: (none)

[e-mail] (Bradley S. Pliner) writes:
> I strongly recommend staying away from RISC-based assembly programming,
> unless it's 100% necessary, and you've eaten your weeties. You have a lot
> to worry about that is not an issue with CISC-based assembly. Foremost,
> pipelined instructions will be a real pain in the butt to work with.

This seems like really strange advice.  The Pentium and 68040 are also
pipelined processors, and they are far more complex to understand and
optomise for than the PowerPC -- so much so that most compilers and
indeed assembly programmers don't even try, but just guess what will
work OK.

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Maynard James Handley)
Date: 24 May 1995 07:47:22 GMT
Organization: University of Otago, Dunedin, NZ

Bruce Hoult ([e-mail]) wrote:
> [e-mail] (Maynard James Handley) writes:
> > I am trying to get to grips with the nitty-gritty of PPC 601 timings and
> > have come across something that does not make sense to me. I'd appreciate
> > any comments people have.
> > Essentiallu what I am trying to figure out is why a floating
> > point store, fpsb, seems to block a subsequent integer store by two clocks.

> The 601 manual talks about this on page I-175.  Each FP store holds in FWA
> for two cycles, blocking both the FP and integer pipes.  Bummer.  This
> makes it faster to move operations using integer loads and stores.  (if
> the memory is cachable)

> -- Bruce

You have misinterpreted what page I-175 means.
You cannot have BACK-TO-BACK fp stores. The 2nd fp store will stall
because the FPSB is in use, and because an fp store goes through the
integer pipeline the integer pipeline freezes.
This DOES NOT mean the integer pipeline freezes for three clocks
whenever you use an fp store. For example if you slot loads
or additions or such like afer the fp store they will go just fine with
no delays---try it. it is only if you slot a second fp store (or as i
explained in my original post, an integer store) that you block.

Using fpstore/fpload as a bit-blt is not always a bad idea. If you
canfit in only the slightest extra work between the stores you come
out ahead.

Maynard


+++++++++++++++++++++++++++

>From [e-mail] (Mark W. Allender)
Date: 24 May 1995 16:01:55 GMT
Organization: Prairienet, the East-Central Illinois Free-Net

Bruce Hoult ([e-mail]) wrote:
: [e-mail] (Bradley S. Pliner) writes:
: > I strongly recommend staying away from RISC-based assembly programming,
: > unless it's 100% necessary, and you've eaten your weeties. You have a lot

: This seems like really strange advice.  The Pentium and 68040 are also
: pipelined processors, and they are far more complex to understand and

BINGO!!!

--
-Mark Allender
-Parallax Software
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Thu, 25 May 1995 15:39:22 +1200 (NZDT)
Organization: (none)

[e-mail] (Maynard James Handley) writes:
> You have misinterpreted what page I-175 means.
> You cannot have BACK-TO-BACK fp stores. The 2nd fp store will stall
> because the FPSB is in use, and because an fp store goes through the
> integer pipeline the integer pipeline freezes.
>
> This DOES NOT mean the integer pipeline freezes for three clocks
> whenever you use an fp store. For example if you slot loads
> or additions or such like afer the fp store they will go just fine with
> no delays---try it. it is only if you slot a second fp store (or as i
> explained in my original post, an integer store) that you block.

So you're saying that a single FP store doesn't freeze the integer pipe
at all -- it's the second FP store that causes the integer line to stall
in sympathy with the FP line?

A small point about "slot loads or additions or such like afer the fp
store": have you allowed for the FP store (or any FP instruction)
being dispatched from high in the instruction queue, while the integer
instructions dispatch only from the bottom slot?

-- Bruce

---------------------------

>From [e-mail] (Tim DeBenedictis)
Subject: Can one do custom controls w-o CDEFs?
Date: Tue, 23 May 1995 00:42:17 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

I was wondering: is it possible to develop a custom control WIHOUT using
a CDEF?

Here's my thoughts on how you'd do it:

1) Write your own control definition procedure.
2) Create a new control via a standard NewControl() call.
3) Replace the pointer to the control definition procedure inside the
control record returned in step 2) with a pointer to my own definition
procedure (step 1) or an equivalent UPP (on the PowerPC).

I haven't tried this at all, yet, but I'm wondering if this is a
hopelessly flawed approach to begin with.

Is there any recommended way of doing a picture-button? (By this, I mean
a simple push-button which displays a picture instead of text, and
displays a different picture when pressed.)  I want to have the
capability of doing something like a toolbar.  (Is there any reccomended
way of doing a toolbar, for that matter?  I hate the things, but it seems
to me that there is no real way around them.)

I'd also like to make a control which contains a TERec, and does what a
TERec would do when clicked, etc.  Is there any quick-n-dirty way to do
this?  Is sample code available anywhere?

Thanks in advance,

-Tim DeBenedictis


+++++++++++++++++++++++++++

>From [e-mail] (Graham)
Date: 23 May 1995 12:02:29 +0100
Organization: Demon Internet

Yes you can. The technique you suggest is ALMOST correct. However, the
defproc "pointer" needs to be a handle, so you need to create a handle
to a routine descriptor, and put that handle in the defproc field. The
code can be embedded in your app code, and of course can be easily
debugged there. I use this technique extensively- MDEF's, CDEFs, LDEFs
all work. If you are not using UPPs, then you need to create a dummy
jump instruction in the handle which jumps to your code. If you need
the code, eMail me.

regards, Graham.

PS. I don't knoe of a "standard" method for picture buttons, but the
CDEf can do naything it needs to, like load pictures, etc. So most
techniques work.

+++++++++++++++++++++++++++

>From [e-mail] (Lord of the Sith)
Date: Tue, 23 May 95 18:04:57 GMT
Organization: Drexel University, Dept. of Math. and Comp. Sci.

Tim DeBenedictis ([e-mail]) wrote:

: I'd also like to make a control which contains a TERec, and does what a
: TERec would do when clicked, etc.  Is there any quick-n-dirty way to do
: this?  Is sample code available anywhere?

Well,  TextEdit, despite the claims made in inside macintosh is anything but
easy.  But, it's by far the easiest way on the mac.  There is no quick and
dirty way.

For source code, follow this url and look around:

http://www.info.apple.com/dev/developerservices.html

somewhere, theres a file with the words TESample in it.  That's it.
If you follow the links developer stuff, and then source code, yuou'll
find it.

: Thanks in advance,

: -Tim DeBenedictis


--
Matt Inger
[e-mail]
http://mcs.drexel.edu/~uminger/
"Remember when you were young?  You shone like the sun."

+++++++++++++++++++++++++++

>From [e-mail] (Jordan Zimmerman)
Date: Wed, 24 May 1995 11:19:32 -0800
Organization: Altura Software, Inc.

> 1) Write your own control definition procedure.
> 2) Create a new control via a standard NewControl() call.
> 3) Replace the pointer to the control definition procedure inside the
> control record returned in step 2) with a pointer to my own definition
> procedure (step 1) or an equivalent UPP (on the PowerPC).

There isn't a "pointer" to a CDEF in the control_h.  It's a Handle to a
CDEF resource.  This creates a major problem for what you want to do.  The
only real way to do this is to use the "6 Byte CDEF trick".  You create a
CDEF that is 6 bytes long and contains the following data "0x4EF9 0000
0000".  At runtime, you fill the zeroes with a pointer to your CDEF in
your app (make sure to flush the caches).

However, this is all just a big kludge.  Is there such a great benefit to
using the Control Manager at all?  The code to track a mouse click fits
into a small function and the CDEF does the rest anyways.  Why not skip
the Control Manager altogether.

--
Jordan Zimmerman, Altura Software
home page: http://www.altura.com/jordanz/home.html
Who is John Galt?

---------------------------

>From Stuart A. Malone <[e-mail]>
Subject: Extracting data from AEDescs
Date: 24 May 1995 14:13:05 GMT
Organization: Massachusetts Institute of Technology

What is the best way of extracting primitive data (like a DescType) from
an AEDesc?  Several of the other types in OSA have routines that will
extract some portion of the data to a pointer in a particular format:

    AppleEvent:      AEGetParamPtr
    AERecord:        AEGetKeyPtr
    AEDescList:      AEGetNthPtr

However, there does not seem to be any corresponding routine when using a
raw AEDesc.  This comes up, for example, when writing object accessor
functions, where the keyForm argument is passed in as an AEDesc.

The best I've been able to come up with is:

    DescType ExtractDescType(const AEDesc * originalDesc)
    {
        AEDesc    tempDesc;
        DescType  result;

        OSErr err = AECoerceDesc(originalDesc, typeType, &tempDesc);
        if (err != noErr) throw err;

        result = **((DescType **)tempDesc.dataHandle);
        AEDisposeDesc(&tempDesc);

        return result;
    }

But it bothers me that I have to extract the data using brute-force
coercion, especially since Apple was saying at WWDC '95 that Copland is
going to move to a pointer-based implementation of AppleScript.  Does
anybody have a better way to accomplish this?

--Stuart A. Malone
MIT Lab for Advanced Technology in the Humanities

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: Wed, 24 May 1995 11:31:43 -0500
Organization: The University of Texas at Austin, Austin, Texas

In article <3pveti$[e-mail]>, Stuart A. Malone
<[e-mail]> wrote:

< What is the best way of extracting primitive data (like a DescType) from
< an AEDesc?  Several of the other types in OSA have routines that will
< extract some portion of the data to a pointer in a particular format:
<
<     AppleEvent:      AEGetParamPtr
<     AERecord:        AEGetKeyPtr
<     AEDescList:      AEGetNthPtr
<
< However, there does not seem to be any corresponding routine when using a
< raw AEDesc.  This comes up, for example, when writing object accessor
< functions, where the keyForm argument is passed in as an AEDesc.
<
< The best I've been able to come up with is:
<
<     DescType ExtractDescType(const AEDesc * originalDesc)
<     {
<         AEDesc    tempDesc;
<         DescType  result;
<
<         OSErr err = AECoerceDesc(originalDesc, typeType, &tempDesc);
<         if (err != noErr) throw err;
<
<         result = **((DescType **)tempDesc.dataHandle);
<         AEDisposeDesc(&tempDesc);
<
<         return result;
<     }
<
< But it bothers me that I have to extract the data using brute-force
< coercion, especially since Apple was saying at WWDC '95 that Copland is
< going to move to a pointer-based implementation of AppleScript.  Does
< anybody have a better way to accomplish this?

Maybe I'm missing something but an AEDesc is a struct consisting of two
fields.  The first is the DescType and you can read it directly.  The
second is the dataHandle and its contents are private to the AppleEvent
Manager (although they're obvious in most cases).

Accessing the DescType is simply a matter of looking at it:

result = tempDesc.descriptorType;

Calling AEDisposeDesc does set the descriptorType to typeNull.

<
< --Stuart A. Malone
< MIT Lab for Advanced Technology in the Humanities

____________________________________________________________________
Brian  Stern  {:-{)}                          [e-mail]
Toolbox commando and Menu bard.             Will FlushCache for Cash

+++++++++++++++++++++++++++

>From Stuart A. Malone <[e-mail]>
Date: 24 May 1995 18:04:20 GMT
Organization: Massachusetts Institute of Technology

Thanks for the response, Brian.

Perhaps I confused matters in my example by using the type DescType,
which is also the type of the descriptorType slot of the AEDesc.  Please
understand that my question is not about extracting the _type_ of the
AEDesc, but the _value_ of the AEDesc.  It just so happens that in the
example I provided, the value _is_ of type DescType.

Let me choose a second example, which might be less confusing.  Suppose
that I have an AEDesc that I wish to convert to a long.  I look at the
descriptorType, and see that it is indeed typeLongInteger.  Great!

How do I extract the long from the AEDesc without doing nasty coercions
on the dataHandle, which as Brian says, is "private to the AppleEvent
Manager"?

--Stuart A. Malone
MIT Lab for Advanced Technology in the Humanities

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D9Oliveiro)
Date: Fri, 26 May 1995 14:04:19 +1200
Organization: University of Waikato

In article <3pveti$[e-mail]>, Stuart A. Malone
<[e-mail]> wrote:

>What is the best way of extracting primitive data (like a DescType) from
>an AEDesc?

Just copy it straight out.

>The best I've been able to come up with is:
>
>    DescType ExtractDescType(const AEDesc * originalDesc)
>    {
>        AEDesc    tempDesc;
>        DescType  result;
>
>        OSErr err = AECoerceDesc(originalDesc, typeType, &tempDesc);
>        if (err != noErr) throw err;
>
>        result = **((DescType **)tempDesc.dataHandle);
>        AEDisposeDesc(&tempDesc);
>
>        return result;
>    }

This looks OK. In Modula-2, I use the following utility routines:

    PROCEDURE CoerceToPtr
      (
        VAR TheDesc : AEDesc;
        ToType : DescType;
        ToData : ADDRESS;
        ToDataSize : Size;
        VAR Err : OSErr
      );
      (* coerces the data in the descriptor to the specified
        type and returns it at the specified location. *)

        VAR
            ResultDesc : AEDesc;

    BEGIN
        IF TheDesc.descriptorType = ToType THEN
          (* just copy the data straight out *)
            BlockMoveData(TheDesc.dataHandle^, ToData, ToDataSize);
            Err := noErr
        ELSE
            InitAEDesc(ResultDesc);
            Err := AECoerceDesc
              (
                (*@theAEDesc :=*) TheDesc,
                (*toType :=*) ToType,
                (*@result :=*) ResultDesc
              );
            IF Err = noErr THEN
                BlockMoveData(ResultDesc.dataHandle^, ToData, ToDataSize)
            END (*IF*);
            DisposeAEDesc(ResultDesc)
        END (*IF*)
    END CoerceToPtr;

    PROCEDURE CoerceToBlock
      (
        VAR TheDesc : AEDesc;
        ToType : DescType;
        VAR ToData : ARRAY OF BYTE;
        VAR Err : OSErr
      );
      (* coerces the data in the descriptor to the specified
        type and returns it at the specified location. *)

    BEGIN
        CoerceToPtr
          (
            (*@TheDesc :=*) TheDesc,
            (*ToType :=*) ToType,
            (*ToData :=*) ADR(ToData),
            (*ToDataSize :=*) SIZE(ToData),
            (*@Err :=*) Err
          )
    END CoerceToBlock;

The latter one is particularly convenient, since the compiler
automatically passes the size of the object for me. You could simulate
this in C with a macro.

>But it bothers me that I have to extract the data using brute-force
>coercion, especially since Apple was saying at WWDC '95 that Copland is
>going to move to a pointer-based implementation of AppleScript.

It doesn't matter what they say. They can't break the existing API, can they?

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Wed, 24 May 1995 14:13:38 -0700
Organization: Internet for the Olympic Peninsula

In article <3pveti$[e-mail]>, Stuart A. Malone
<[e-mail]> wrote:

> What is the best way of extracting primitive data (like a DescType) from
> an AEDesc?  Several of the other types in OSA have routines that will
> extract some portion of the data to a pointer in a particular format:
>
>     AppleEvent:      AEGetParamPtr
>     AERecord:        AEGetKeyPtr
>     AEDescList:      AEGetNthPtr
>
> However, there does not seem to be any corresponding routine when using a
> raw AEDesc.  This comes up, for example, when writing object accessor
> functions, where the keyForm argument is passed in as an AEDesc.
>
> The best I've been able to come up with is:
>
>     DescType ExtractDescType(const AEDesc * originalDesc)
>     {
>         AEDesc    tempDesc;
>         DescType  result;
>
>         OSErr err = AECoerceDesc(originalDesc, typeType, &tempDesc);
>         if (err != noErr) throw err;
>
>         result = **((DescType **)tempDesc.dataHandle);
>         AEDisposeDesc(&tempDesc);
>
>         return result;
>     }

For a variety of reasons, if you can use the AE...Ptr () series, rather
than the AE...Desc () series of calls, you're better off.  In the case of
typeType, you can (unless you are allowing for a list of typeTypes...there
you ask for a list (using AEGetParamDesc(), and then ask for each one by
pointer).  Just ask for the value more directly using AEGetParamPtr ()
rather than AEGetParamDesc ().  You can include the coercion directly in
the AEGetParamPtr ().

The AE...Ptr () series is better because it saves some Memory Manager
activity (one NewHandle/DisposeHandle pair) and because you don't have a
descriptor you can forget to dispose.

> But it bothers me that I have to extract the data using brute-force
> coercion, especially since Apple was saying at WWDC '95 that Copland is
> going to move to a pointer-based implementation of AppleScript.  Does
> anybody have a better way to accomplish this?

The AE...Ptr () series should also help insulate you from whatever changes
are made at Copland time.

If you remember that an AppleEvent isn't really a collection of
descriptors for attributes and parameters, but just one flattened mass,
that can make it easier to use the ...Ptr series.  [Same is <currently>
true for lists and records...AppleEvent is basically two AERecords laid
end to end (attributes, then parameters).  With some up-front boilerplate,
including offsets to the attribute record and the parameter record.]

Reading the AEGizmoes code from Jens Alfke may help....on the other hand,
it may cause terminal confusion.  [It's good code; the subject matter is
confusing.]

- -------
Unfortunately, one case which forces AEDesc () usage for the output is
explicit coercion calls.  Other forced AEDesc uses are in the Object Model
library area.

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       I don't do windows.
   [e-mail]

---------------------------

>From [e-mail] (PaulS101)
Subject: Getting rid of Option-
Date: 19 May 1995 23:49:40 -0400
Organization: America Online, Inc. (1-800-827-6364)

   This may sound like a simple question, but it has me beat!
   Is there any simple way to convert an option-key combo to the plain
key? (or from the keyboard location code to the char.)
   I'm presently using a table lookup and it stinks (I want to eventually
support customable menus.)  I can't just use Mercutio because I don't have
the time to build it into PowerPlant just now.
   It seems like KeyTrans() should do this somehow, but I can't seem to
figure it out and I don't have the time to do exhaustive experimenting.
Has anyone else solved this?

Thanks all,
Paul

+++++++++++++++++++++++++++

>From [e-mail] (Grobbins)
Date: Mon, 22 May 1995 22:06:01 -0700
Organization: Skunkworks

In article <3pjosk$[e-mail]>, [e-mail] (PaulS101)
wrote:
>   Is there any simple way to convert an option-key combo to the plain
>key? (or from the keyboard location code to the char.)

If you have the virtual keyCode and modifiers from the EventRecord, just
munge the modifiers and pass them to KeyTrans.  That would look something
like this, where state is initially zero:

  kchrNum = GetScript(GetEnvirons(smKeyScript), smScriptKeys)
  kchrResHandle = RGetResource('KCHR', kchrNum);
  if (kchrResHandle != nil) {
    modifiedKeyCode =
      ((keyCode & 0x007F) | (alteredModifiers & 0xFF80));
    theChar = KeyTrans(*kchrResHandle, modifiedKeyCode, &state);
  }


Grobbins                            [e-mail]

---------------------------

>From [e-mail] (Ralf Lehmann)
Subject: How to disable Text Item ?
Date: 25 May 1995 21:02:44 GMT
Organization: Brigham Young University

How does one disable a text item in a Dialog ? I tried
GetDItem and SetDItem, modifying the 8th bit in the
iType field, but I still get the blinking caret in the
field and I'm still able to enter chars (with only a
minor behavior difference in ModalDialog: it returns
only once I hit another item).
Any help welcome.

Ralf.

+++++++++++++++++++++++++++

>From [e-mail] (Mel Patrick)
Date: Thu, 25 May 1995 16:14:05 -0700
Organization: Internet Direct, Inc.

In article <[e-mail]>,
[e-mail] (Ralf Lehmann) wrote:

> How does one disable a text item in a Dialog ? I tried
> GetDItem and SetDItem, modifying the 8th bit in the
> iType field, but I still get the blinking caret in the
> field and I'm still able to enter chars (with only a
> minor behavior difference in ModalDialog: it returns
> only once I hit another item).
> Any help welcome.
>
> Ralf.

Look for a toolbox routine called HIDEDITEM(DLOGPtr,theItem). Basically it
moves the dialog item off screen and kills the textedit update from
happening to the field. Of course this answer assumes that you want the
item not to be visible. Which incidently your message didn't say (a point
in future might be to explain what results you want)...

If all you want to do is deactivate the edit field itself, look for the
toolbox routine called, "TEDeactivate(hTe)". Use the GETDITEM to get a
handle to edit field, and then the tedeactivate to stop the caret from
doing its thing.

--
Mel Patrick
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Dave Polaschek)
Date: Fri, 26 May 1995 06:51:17 -0500
Organization: LaserMaster

In article <[e-mail]>,
[e-mail] (Ralf Lehmann) wrote:

> How does one disable a text item in a Dialog ? I tried
> GetDItem and SetDItem, modifying the 8th bit in the
> iType field, but I still get the blinking caret in the
> field and I'm still able to enter chars (with only a
> minor behavior difference in ModalDialog: it returns
> only once I hit another item).
> Any help welcome.
>
> Ralf.

The way I handle it is to 1) TESetSelect() the selection to nothing,
2) TEDeactivate the current editText item (if the item I'm disabling is
the current one), 3) Select the next editText item's text, 4) change the
type of the item from editText to statText, 5) get the rectangle that
covers the item and the frame (InsetRect(&itemRect,-4,-4)) and 6)
EraseRect() and InvalRect() that rectangle so the item is forced to
redraw.

This avoid the problem of still having TextEdit think the cursor's
still in an item I've turned off. If you don't have another editText
item to select, things get trickier. You'll need to do the TESetSelect
and TEDeactivate, though.

-DaveP
--
Dave Polaschek -- work:[e-mail] -- home:[e-mail]
Vending machines SHOULD respond to a [finger] request with a list of
all items currently available for purchase... -RFC1288

+++++++++++++++++++++++++++

>From [e-mail] (Byron Han)
Date: Fri, 26 May 1995 20:14:44 GMT
Organization: Institute for Astronomy, Hawaii

In article <[e-mail]> [e-mail] (Ralf Lehmann) writes:
>How does one disable a text item in a Dialog ? I tried
>GetDItem and SetDItem, modifying the 8th bit in the
>iType field, but I still get the blinking caret in the
>field and I'm still able to enter chars (with only a
>minor behavior difference in ModalDialog: it returns
>only once I hit another item).
>Any help welcome.

Call HideDItem, GetDItem, SetDItem, ShowDItem

The SetDItem is used to change the item type from editText to statText.
The Hide/Show are required to have the dialog manager take care of
deactivating the text edit item.


--
 Byron Han, Graduate Student        University of Hawai`i at Mano`a
 Institute for Astronomy                 Email: [e-mail]
 Quote: "Given current global population growth rates, reproduction
                  will soon no longer be a right but a priviledge."

---------------------------

>From [e-mail] (Brian Quinlan)
Subject: To OOP or not to OOP. That...
Date: 10 May 95 07:25:44 GMT
Organization: Simon Fraser University

I'm writing a medium sized program right now using a combination of object
oriented and procedural code. For example, I use objects for my windows and
most of my data structures but not my event loop. I can't seem to decide
whether to use object oriented techniques on code that, if it was object
oriented, could have only one instance. For example, why would I make my
preferences code into an object? It could have only one instance and wouldn't
provide any additional abstraction. Any opinions?

Brian Quinlan
[e-mail]

--

Brian Quinlan
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Igor Popovic)
Date: 12 May 1995 04:23:30 GMT
Organization: Yale University

Brian Quinlan ([e-mail]) wrote:
: I'm writing a medium sized program right now using a combination of object
: oriented and procedural code. For example, I use objects for my windows and
: most of my data structures but not my event loop. I can't seem to decide
: whether to use object oriented techniques on code that, if it was object
: oriented, could have only one instance. For example, why would I make my
: preferences code into an object? It could have only one instance and wouldn't
: provide any additional abstraction. Any opinions?

there probably is no immediately apparent advantage in having your
preferences objectified (for example) but in the long run and in a large
program it might be convenient to have a class CPreferenceServer (or
CPreferenceManager or something along these lines) with just
one instance (presumably a global one), mainly as a means to
bundle a bunch of preference-related functions (reading, setting,
saving ...) as methods. but i guess it's really mainly a matter
of style, for me it helps to think of my programs as a bunch of
specialized objects, each responsible for a specific task or class
of tasks, ideally sitting in its own source file and quite
independent of the others. --Igor++

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: Thu, 11 May 1995 23:51:12 -0500
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>, [e-mail] (Brian Quinlan)
wrote:

< I'm writing a medium sized program right now using a combination of object
< oriented and procedural code. For example, I use objects for my windows and
< most of my data structures but not my event loop. I can't seem to decide
< whether to use object oriented techniques on code that, if it was object
< oriented, could have only one instance. For example, why would I make my
< preferences code into an object? It could have only one instance and wouldn't
< provide any additional abstraction. Any opinions?
<
< Brian Quinlan
< [e-mail]

If you ever write a second application you might reuse your preferences
class.  I've written a prefs class (actually I've got a version for TCL
and one for PP).  This class inherits from the file class of the framework
so it automatically knows about opening, closing, specifying, and other
file related stuff.  My prefs base class knows about the Preferences
folder, it knows how to read in the preferences handle, it knows how to
create itself if it doesn't exist and it's asked to open itself, it knows
how to update the preferences handle if it's dirty.  The derived class
provides the name and creator of the file, it allocates the prefs handle
and fills it with the default values, and it provides the accessor
function(s) as needed.  Reuse of this class means that I'll only have to
write a constructor that is a few lines and the createdefault methods.
(If I'm good I'll write the verifyprefs method as well).

The event loop is exactly the sort of code that I don't want to look at.
When I start a new project I don't want to start cutting and pasting event
loops and handleMouseDown code from my old projects.  I just want to
inherit from a nice application class that takes care of all that and
calls my code when something interesting is going to happen.

I find that working like this saves my time and things tend to work
better, sooner.

Cheers,

____________________________________________________________________
Brian  Stern  {:-{)}                          [e-mail]
Toolbox commando and Menu bard.             Will FlushCache for Cash

+++++++++++++++++++++++++++

>From [e-mail] (WDW)
Date: Fri, 12 May 1995 00:32:25 +0200
Organization: PING Belgium

In article <[e-mail]>, [e-mail] (Brian Quinlan)
wrote:

>For example, why would I make my
>preferences code into an object? It could have only one instance and wouldn't
>provide any additional abstraction. Any opinions?
>
>Brian Quinlan

Yes, to re-use of your code, in the future you can use the same class (from your library) or eventually create a subclass with trivial overridings.
In some frameworks (ie MacApp) there is even a class for Str255, IMHO this goes too far ...

Willy

--
Willy De Waele
Internet: [e-mail]                  AppleLink: DEWAELE.W
TAKE & GIVE (GUIDE)

+++++++++++++++++++++++++++

>From [e-mail] (Gregory Lo)
Date: Fri, 12 May 1995 06:54:23 -0400
Organization: Queen's University

In article <3ouns2$[e-mail]>, [e-mail]
(Igor Popovic) wrote:

>Brian Quinlan ([e-mail]) wrote:
>: I'm writing a medium sized program right now using a combination of object
>: oriented and procedural code. For example, I use objects for my windows and
>: most of my data structures but not my event loop. I can't seem to decide
>: whether to use object oriented techniques on code that, if it was object
>: oriented, could have only one instance. For example, why would I make my
>: preferences code into an object? It could have only one instance and wouldn't
>: provide any additional abstraction. Any opinions?
>

[Everything Igor said goes for me too]

I agree with all of what Igor wrote in reply.  I also think that a
well-built preference class helps in terms of code reuse.  You could use
the same basic code in several different projects, with a minimum of
modification for specialized functionality.

- ---------------------------------------------------------
Gregory Lo  GLo ?:^(>      <mailto:[e-mail]>
<mailto:[e-mail]>      <mailto:[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 12 May 1995 12:11:22 GMT
Organization: Ecole Normale Superieure, Paris

In article <[e-mail]>,
Brian Quinlan <[e-mail]> wrote:

>oriented, could have only one instance. For example, why would I make my
>preferences code into an object? It could have only one instance and wouldn't
>provide any additional abstraction. Any opinions?

My preferences class has one virtual method, GetDefaultSetting,
whose job is to provide default settings. This way the base class
is the same for all programs I write, and I override it in each
program to define defaults. Looks great.



--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/ ...

+++++++++++++++++++++++++++

>From [e-mail] (Alain Roy)
Date: Fri, 12 May 1995 13:57:03 GMT
Organization: None

In article <[e-mail]>,
[e-mail] (Brian Stern) wrote:

>If you ever write a second application you might reuse your preferences
>class.

I recently wrote a bunch of C code to deal with preferences.

When I moved it to another application, it took about 5 minutes or less to
get it working, and that was just because the preferences themselves
changed.

When I moved it to yet another application that needed something different
(variable length preferences instead of static length), it took me maybe
20 minutes to modify the code. (I suspect that the same thing would happen
in C++ if you made the same assumption of static length preferences
originally that I did.)

Why would C++ make my code here more reusable? I seemed to reuse it in C
just fine.

(This isn't a flame, but I'm honestly curious about the answer. I use C++,
but only in small doses.)

-alain

+++++++++++++++++++++++++++

>From [e-mail] (David J. Whitney)
Date: 13 May 1995 01:07:26 GMT
Organization: Computer Science Department, Stanford University.
In article <[e-mail]>, [e-mail] (Alain Roy) writes:
|> In article <[e-mail]>,
|> [e-mail] (Brian Stern) wrote:
|>
|> >If you ever write a second application you might reuse your preferences
|> >class.
|>
|> I recently wrote a bunch of C code to deal with preferences.
|>
|> When I moved it to another application, it took about 5 minutes or less to
|> get it working, and that was just because the preferences themselves
|> changed.
|>
|> When I moved it to yet another application that needed something different
|> (variable length preferences instead of static length), it took me maybe
|> 20 minutes to modify the code. (I suspect that the same thing would happen
|> in C++ if you made the same assumption of static length preferences
|> originally that I did.)
|>
|> Why would C++ make my code here more reusable? I seemed to reuse it in C
|> just fine.
|>
|> (This isn't a flame, but I'm honestly curious about the answer. I use C++,
|> but only in small doses.)

The issue here isn't really C++ vs C.  Sure an object and a well written C
library can operate very similarly.  What is important is Object Oriented
*Design*.  Thinking of things in terms of data, and not in terms of functions.
That is what has saved me countless hours of C code tweaking and subsequent
ripple effects through out the rest of my code.

The gain with OOP is that when you have 20 applications based on that
Preference Manager and you come a across a bug, you have to change it 20
times.  Or just fix your object and relink.  Note that this can be said also
of a well written C library with consistent API.  But how many consistent APIs
do you have lying around?  OOP forces (allows, encourages?) you to have a
consistent API to your objects.

But even more, it is thinking in terms of data.  Procedures fall out from what
the data is you are using.  Not the other way around.  I took a 5 day class
(work paid) on Object oriented design (anyone can pick up C++), and that
changed my outlook completely.  It's hard to describe, and making the switch
*is* hard, but my life is so much simpler now.  Given the choice between
learning OO programming and OO design, learn to design first.

disclaim, disclaim, disclaim.  your mileage may vary.

-Dave

--
____________________________________________________________________________
David Whitney              | Cooper:  Wanna know why I'm whittling?
[e-mail] | Truman:  OK, I'll bite.  Why are you whittling?
Graphics and Visualization | Cooper:  Because that's what you do in a
Sterling Software          |          town where a yellow light still means
NASA Ames, Mtn View, CA    |          slow down,  not speed up.
          Not an indication of Sterling or NASA's opinion

+++++++++++++++++++++++++++

>From Seth Tager <sdt>
Date: 12 May 1995 06:19:16 GMT
Organization: Brown University

[e-mail] (Brian Quinlan) wrote:
>I'm writing a medium sized program right now using a combination of object
>oriented and procedural code. For example, I use objects for my windows and
>most of my data structures but not my event loop. I can't seem to decide
>whether to use object oriented techniques on code that, if it was object
>oriented, could have only one instance. For example, why would I make my
>preferences code into an object? It could have only one instance and wouldn't
>provide any additional abstraction. Any opinions?

I think this is an interesting question. If you already have working code and
you can't imagine the program growing beyond a managable size then you're
probably better off sticking with what you've got in order to avoid 1) having
to debug code that already works, and 2) the possibility (or probability)
that you will wind up coding yourself into spaghetti by incrementally designing
and implementing the "once-only" application code. If you look at some mature
application frameworks (the Think Class Library, for example) you'll see that
they manage to get reuse and maintainability out of some of the ways that
they use their application classes (which take care of things like the event
loop).

As far as something like preferences goes, there are ways you could save
yourself some work by identifying the abstract behavior of preferences.
For example, are preferences saved in resources, as a separate data file,
or some other way? (or a combination of these) The mechanism for storing data
is something that you'll probably use more than once. If not in this program
then definitely in the next. If you can establish a scheme that works for you
then you'll save yourself time in the long run.

Commercial frameworks are something to consider (eventually). If you're far
enough along with the project you're working on then you might want to just
get it finished. The good things about established frameworks is that
someone (expert?) has spent a lot of time working out the problems. They're
good to study just to get some ideas. Drawbacks are 1) steep
learning curve and 2) you become heavily invested in someone else's work. If
it breaks or becomes obsolete (they stop supporting it) your out of luck.

Hope this helps,
Seth


+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Sun, 14 May 1995 19:22:46 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <[e-mail]>, [e-mail] (Brian Quinlan)
wrote:

> I'm writing a medium sized program right now using a combination of object
> oriented and procedural code. For example, I use objects for my windows and
> most of my data structures but not my event loop. I can't seem to decide
> whether to use object oriented techniques on code that, if it was object
> oriented, could have only one instance. For example, why would I make my
> preferences code into an object? It could have only one instance and wouldn't
> provide any additional abstraction. Any opinions?

If it ain't broke, don't fix it. I've seen cases where programmers rewrite
fully working code just because it's not object oriented.

If you really want to start breaking out usable modules, you could indeed
write a preferencefile class, or something similar, instantiate it  and
use it inside your procedural environment. Then again if you spend a lot
of time writing a class, and all it does is to read and write a simple
preference setting, maybe a WriteMyPreferences() and ReadMyPreferences()
is all you need. I also think that copy/paste is a very powerful code
reusability technique.

--Kent

--
Kent Sandvik   [e-mail]                  Working with Multimedia stuff...
Apple Developer Technical Support.                                     Private activities on Internet.

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 15 May 1995 11:20:32 GMT
Organization: Ecole Normale Superieure, Paris

In article <sandvik-1405951922460001@17.255.38.116>,
Kent Sandvik <[e-mail]> wrote:

>I also think that copy/paste is a very powerful code
>reusability technique.

But it becomes a pain when your code is shared between several
projects.  And that is bound to happen to all professionals and even
serious hobbyists.

--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/ ...

+++++++++++++++++++++++++++

>From [e-mail] (Mark H. Linton)
Date: 15 May 95 11:42:05 EST
Organization: HRB Systems, Inc.

In article <3p10oe$[e-mail]>,
   [e-mail] (David J. Whitney) writes:
> The issue here isn't really C++ vs C.

True statement...

> Sure an object and a well written C library can operate very similarly.

In fact they can be identical (e.g. CFront)

> What is important is Object Oriented *Design*.

Again, true.

> Thinking of things in terms of data, and not in terms of functions.

You are thinking of Jackson Structured Design (JSD) originally
described by Micheal Jackson (not the singer). Also, my personal
favorite =^) although, not the ONLY OOD technique. Booch comes to
mind fairly quickly.

> That is what has saved me countless hours of C code tweaking and
> subsequent ripple effects through out the rest of my code.

To be replaced by countless hours of C++ code tweaking, perhaps? =^)

> The gain with OOP is that when you have 20 applications based on
> that Preference Manager and you come a across a bug, you have to
> change it 20 times.  Or just fix your object and relink.

Or just fix your library and relink.

> Note that this can be said also of a well written C library with
> consistent API.  But how many consistent APIs do you have lying
> around?

For the naive reader, note here that the comment about the
consistency of APIs does not mention languages. It is just as easy
to write an inconsistent API in C++ as with C. And, in fact, this
is the case. The API is a function of the designer and not the
language. OOA/OOD/OOP is an attempt to educate the designers. C++
does support enforcement mechanisms for some of the concepts, but
they do not force you to do a good design. Design pre-dates
coding, so that by the time you get to your first compile (the
first chance the language gets to help you) it is already too
late. This was Grady Booch's idea in trying to develop tools that
would allow you to do OOA/OOD before you had to worry about doing
OOP.

> OOP forces (allows, encourages?) you to have a
> consistent API to your objects.

False. OOP forces you to STICK TO you consistent API assuming that
you have put one in place in your design. It also allows you to
modify your IMPLEMENTATION of you design without breaking your
API.

> But even more, it is thinking in terms of data.  Procedures fall
> out from what the data is you are using.  Not the other way
> around.  I took a 5 day class (work paid) on Object oriented
> design (anyone can pick up C++), and that changed my outlook
> completely.  It's hard to describe, and making the switch *is*
> hard, but my life is so much simpler now.  Given the choice
> between learning OO programming and OO design, learn to design
> first.

...and this explains why he has a consistent API (me too, BTW)...

Definitely, most emphatically, YES. Take a class at your local
university. Even if you consider yourself an expert, it will be a
real eye-opener. I figure your future is worth a couple of hundred
bucks (your employeer should, also).

> disclaim, disclaim, disclaim.  your mileage may vary.

Not really a flame, just a clarification. =^)

> -Dave
>
> --
> ____________________________________________________________________________
> David Whitney              | Cooper:  Wanna know why I'm whittling?
> [e-mail] | Truman:  OK, I'll bite.  Why are you whittling?
> Graphics and Visualization | Cooper:  Because that's what you do in a
> Sterling Software          |          town where a yellow light still means
> NASA Ames, Mtn View, CA    |          slow down,  not speed up.
>           Not an indication of Sterling or NASA's opinion
--
Hope this helps.

Mark H. Linton
____________________________________________________________________
mark \'mdrk\ n [ME, fr. OE mearc boundary, march, sign; akin to OHG
marha boundary, L margo] 1 a : a conspicuous object serving as a guide
for travelers 2 : A standard or criterion of quality 3 : An object or
point that serves as a guide --idiom. mark time. 1 : To make little or
no progress

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D9Oliveiro)
Date: Tue, 16 May 1995 11:41:44 +1200
Organization: University of Waikato

In article <[e-mail]>,
[e-mail] (Alain Roy) wrote:

>In article <[e-mail]>,
>[e-mail] (Brian Stern) wrote:
>
>>If you ever write a second application you might reuse your preferences
>>class.
>
>I recently wrote a bunch of C code to deal with preferences.
>
>When I moved it to another application, it took about 5 minutes or less to
>get it working, and that was just because the preferences themselves
>changed.
>
>When I moved it to yet another application that needed something different
>(variable length preferences instead of static length), it took me maybe
>20 minutes to modify the code. (I suspect that the same thing would happen
>in C++ if you made the same assumption of static length preferences
>originally that I did.)
>
>Why would C++ make my code here more reusable? I seemed to reuse it in C
>just fine.

This is a valid question to ask, and judging from reports I've been
reading, C++ (and OOP in general) hasn't been making much difference to
the amount of code that people have been able to reuse.

I like to think I've been having quite a good success rate with reusable
code myself, using techniques that have little or nothing to do with
"object-orientation"--I've done a couple of fully AppleScriptable,
recordable applications with better than 60% code reuse.

To give you an idea of how I did it, I've just publicly released my entire
collection of standard libraries. Have a look at
<http://www2.waikato.ac.nz/ldo/sw/index.html#MyModLib>.

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

>From [e-mail] (Ari Halberstadt)
Date: Thu, 18 May 1995 00:19:57 -0400
Organization: North Shore Access/Eco Software, Inc; ([e-mail])

In article <sandvik-1405951922460001@17.255.38.116>, [e-mail]
(Kent Sandvik) wrote:

> In article <[e-mail]>, [e-mail] (Brian Quinlan)
> wrote:
>
> > I'm writing a medium sized program right now using a combination of object
> > oriented and procedural code. For example, I use objects for my windows and
> > most of my data structures but not my event loop. I can't seem to decide
> > whether to use object oriented techniques on code that, if it was object
> > oriented, could have only one instance. For example, why would I make my
> > preferences code into an object? It could have only one instance and
wouldn't
> > provide any additional abstraction. Any opinions?
>
> If it ain't broke, don't fix it. I've seen cases where programmers rewrite
> fully working code just because it's not object oriented.
>
> If you really want to start breaking out usable modules, you could indeed
> write a preferencefile class, or something similar, instantiate it  and
> use it inside your procedural environment. Then again if you spend a lot
> of time writing a class, and all it does is to read and write a simple
> preference setting, maybe a WriteMyPreferences() and ReadMyPreferences()
> is all you need. I also think that copy/paste is a very powerful code
> reusability technique.

Sometimes it ain't broke until the system changes. I have a C program I
was working on, and it stored prefs as bitmapped structures (not
graphics!). This was all fine and dandy with 68k programs, but became a
pain with PPC programs. I'd have things like this in my code (which I did
to get a quick port):

/* comment to explain this mess */
#if PRAGMA_ALIGN_AVAILABLE // shut up THINK C
   #pragma align=mac68k
#endif
typedef struct {
   short font;
   short style;
   ...
} tPortTextSettings;
#if PRAGMA_ALIGN_AVAILABLE // shut up THINK C
   #pragma align=reset
#endif

A pain, but it worked, assuming I remembered to keep all my pragmas in
order. But wait, I then decided to use floating point numbers to store
coordinates, so my window records contained rectangles that could be made
of floating point values. There is no such thing as a common floating
point format (there are several, but you can't convince your compiler to
use them when you need 'em), so I use extended80 since it's a mac only
program and it's easy to convert to/from long double/extended80. Whoops,
no more bitmapped structures.

Time to get rid of those ugly pragmas anyway. Time for what? A streams
library. Cool, now I stream my data. Doesn't this thing come with C++? Oh
well, I wrote it from scratch. Not hard. It does have ugly switch
statements to go to file, resource, handle, pointer, not as easily
extensible as a class. Now, to save my floating point numbers, I made a
typed stream library, bundled it all together, and rewrote my data saving
routines (not too many for this app). The typed stream library does a few
other useful things.

In the end, I didn't change my preferences file library, but I did change
the IO routines for my preferences and other data. Hmm, I'm not sure how
this ties in with this thread, except that I think it might have been
easier to use C++, a framework, and someone else's streams (or to have
coded it that way in the first place), and it has little to do with code
reuse in this instance. Though this thread was also about prefs, so I
thought I'd babble a bit.

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Wed, 17 May 1995 22:01:50 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <3p7de1$[e-mail]>, [e-mail] (Francois
Pottier) wrote:

> In article <sandvik-1405951922460001@17.255.38.116>,
> Kent Sandvik <[e-mail]> wrote:
>
> >I also think that copy/paste is a very powerful code
> >reusability technique.
>
> But it becomes a pain when your code is shared between several
> projects.  And that is bound to happen to all professionals and even
> serious hobbyists.

That's why I like Metrowerks and the path statement settings, most of my
common code is in a specific folder...

--Kent

--
Kent Sandvik   [e-mail]                  Working with Multimedia stuff...
Apple Developer Technical Support.                 Private activities on Internet.

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Wed, 17 May 1995 22:06:51 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <ldo-1605951141440001@130.217.96.144>, [e-mail] wrote:
> I like to think I've been having quite a good success rate with reusable
> code myself, using techniques that have little or nothing to do with
> "object-orientation"--I've done a couple of fully AppleScriptable,
> recordable applications with better than 60% code reuse.

Hear hear! Actually I program nowadays in plain C with sort of object-ism
by passing around known structures, ok I call them objects, from one
function to another. As I spend most of my time with QT programming
nowadays, I pass around movies,tracks, movie controllers and so on. I have
for instance a function for checking if a particular media type is present
in a movie, called QTUMediaTypeInTrack. It takes a movie and a media type,
returns true or false. Pretty simple, it's encapsulating code, and no C++
needed.

C++ is sometimes nice for hiding global state, I must admit...

--Kent
PS: Check out,
ftp://ftp.info.apple.com/dts/dtsqtutils.May95.hqx

--
Kent Sandvik   [e-mail]                  Working with Multimedia stuff...
Apple Developer Technical Support.                 Private activities on Internet.

+++++++++++++++++++++++++++

>From [e-mail] (Jay Farrell)
Date: Thu, 18 May 1995 09:36:53 -0500
Organization: Jayfar's Web

In article <sandvik-1705952206510001@17.255.38.116>, [e-mail]
(Kent Sandvik) wrote:

[deleted]

> PS: Check out,
> ftp://ftp.info.apple.com/dts/dtsqtutils.May95.hqx
>
To which Fetch responds: No Such File...

Jayfar
- -------------------------------------------------------------------
 Jay Farrell                    <URL:http://www.netaxs.com/~jayfar/>
 [e-mail]
 Philadelphia, Pennsylvania, USA
  ///////////////////////////////////////////////////////////////////
 /// The Mops Page <URL:http://www.netaxs.com/~jayfar/mops.html> ///
///////////////////////////////////////////////////////////////////

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Sun, 21 May 1995 14:54:13 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <[e-mail]>,
[e-mail] (Jay Farrell) wrote:

> In article <sandvik-1705952206510001@17.255.38.116>, [e-mail]
> (Kent Sandvik) wrote:
>
> [deleted]
>
> > PS: Check out,
> > ftp://ftp.info.apple.com/dts/dtsqtutils.May95.hqx
> >
> To which Fetch responds: No Such File...

Ouch, sorry, me and too many URLs in my brain; the real one (after
triple-checking) is:

ftp://ftp.info.apple.com/dts/quicktime/dtsqtutils.May95.hqx

It's worth checking that quicktime sub-directory now and then as we upload
QuickTime related material into this place.

--Kent

--
Kent Sandvik   [e-mail]                  Working with Multimedia stuff...
Apple Developer Technical Support.                 Private activities on Internet.

---------------------------

>From [e-mail] (Paul DuBois)
Subject: TransSkel 3.20 is available (CW 6 - SC++ 8)
Date: 26 May 1995 18:38:47 -0500
Organization: Castra Parvulorum

Release 3.20 of TransSkel, a skeleton for Macintosh application development
under MetroWerks C or Symantec C++/THINK C, is now available.

This is an update release; it compiles under MetroWerks CodeWarrior 6
(PPC or 68K) as well as Symantec C++ (PPC) and THINK C 8 (68K).

TransDisplay 3.09 and TransEdit 3.09 are also available now, and have been
updated in similar ways.  TransDisplay and TransEdit are modules that can
be dropped into TransSkel-based projects to provide display-only or editable
text windows.

TransSkel, TransDisplay, and TransEdit are available via any of the following:

anonymous ftp to ftp.primate.wisc.edu (under /pub/mac/TransSkel)

gopher to gopher.primate.wisc.edu, then select "Primate Center Software
Archives")

WWW using URL http://www.primate.wisc.edu/software/mac/TransSkel/.

--
Paul DuBois
[e-mail]

"I'm going to learn worm-talk next," said Janetta  -- Grandaddy's Place

---------------------------

>From [e-mail] (Sam Huffman)
Subject: malloc vs. NewPtr
Date: 17 May 1995 16:36:25 GMT
Organization: University of Michigan

Can anyone tell me exactly what the difference is between using the ANSI
malloc() and the Toolbox NewPtr() for allocating memory? My understanding
is that malloc is more standard and more efficient. So why would one use
NewPtr?

I have an ulterior motive in asking this question. In a program I am
writing I make use of several linked lists. The program must run on both
UNIX and Mac platforms, so I have been separating the interface from the
lower-level functions. To facilitate this, I tried to use malloc when
allocating memory for the list. For some reason, however, the memory
returned by malloc was already in use by the system (I first figured this
out when, after writing to one of the memory locations, my menubar turned
purple =) Upon closer examination, the memory addresses I was getting
seemed to be in the range xC02 and upward. I had always been under the
impression that lower memory values were reserved by the system. When I
switched to NewPtr, everything worked fine and my memory range seemed to
be more logical.

So, can anyone tell me
1) Why malloc is giving me memory that is already in use,
2) How I can get it to give me my own memory rather than someone else's
3) Would I be better off just using NewPtr (time isn't critical here) and
changing it to malloc for the UNIX implementation

Thank you very much.

Sam Huffman
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Mark W. Allender)
Date: 18 May 1995 13:06:45 GMT
Organization: Prairienet, the East-Central Illinois Free-Net

Sam Huffman ([e-mail]) wrote:
: So, can anyone tell me
: 1) Why malloc is giving me memory that is already in use,

What you described sounds very strange indeed.  What compiler/linker setup
are you using.  I have never seen this behaviour with either CW5 or MPW C.

: 2) How I can get it to give me my own memory rather than someone else's

It should do that.  Something else is wrong here.

: 3) Would I be better off just using NewPtr (time isn't critical here) and
: changing it to malloc for the UNIX implementation

This question is a good one.  I have talked with several people who have
told me different things.  If speed is not important, and portability is, I
would use malloc (assuming that it is working properly).  malloc will give
you a pointer just like NewPtr will.  If speed is important, then I can't
answer the question for you.  I am using NewPtr in my apps, but I have put
a wrapper around all of my memory allocation and free calls so that I can
change the method of allocation easily.  (I can also track down annoying
little memory problems this way too!).

--
-Mark Allender
-Parallax Software
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Hank Dolben)
Date: Thu, 18 May 1995 16:11:03 -0400
Organization: University of New Hampshire

In article <schmeul-1705951234020001@162.48.124.18>, [e-mail]
(Sam Huffman) wrote:

> Can anyone tell me exactly what the difference is between using the ANSI
> malloc() and the Toolbox NewPtr() for allocating memory?

I don't know what development system you use. In the THINK C ANSI library
(the version I have), malloc is implemented by calling NewPtr. So, it's
*not* more efficient. I use malloc for "portable" code and NewPtr for
strictly Mac code to avoid having to include the ANSI library. I haven't
had any trouble with malloc when I've used it. Maybe a time bomb went off
for you, i.e., a bug may still be lurking in your code (that's always a
safe bet isn't it? :-).

Hank Dolben                                   Space Science Center
[e-mail]                    University of New Hampshire

+++++++++++++++++++++++++++

>From [e-mail] (Hank Dolben)
Date: Fri, 19 May 1995 09:26:16 -0400
Organization: University of New Hampshire

In article <[e-mail]>, I wrote:

> In the THINK C ANSI library (the version I have), malloc is implemented by
> calling NewPtr. So, it's *not* more efficient.

OK, that was a bogus thing to say. Excuse me. Of course, it *is* possible
to improve efficiency by adding a layer of software. I do it all the time.
In fact, I don't know whether or not the THINK C implementation of malloc
accomplishes this. I'd have to test it, just as I do my own attempts.

Hank Dolben                                   Space Science Center
[e-mail]                    University of New Hampshire

+++++++++++++++++++++++++++

>From [e-mail] (Ken Prehoda)
Date: Fri, 19 May 1995 10:06:08 -0500
Organization: Univ of Wisc-Madison, Dept of Biochemistry

In article <3pfgp5$[e-mail]>, [e-mail] (Mark
W. Allender) wrote:

: Sam Huffman ([e-mail]) wrote:
: : So, can anyone tell me
: : 1) Why malloc is giving me memory that is already in use,
:
: What you described sounds very strange indeed.  What compiler/linker setup
: are you using.  I have never seen this behaviour with either CW5 or MPW C.
:
: : 2) How I can get it to give me my own memory rather than someone else's
:
: It should do that.  Something else is wrong here.
:
: : 3) Would I be better off just using NewPtr (time isn't critical here) and
: : changing it to malloc for the UNIX implementation
:
: This question is a good one.  I have talked with several people who have
: told me different things.  If speed is not important, and portability is, I
: would use malloc (assuming that it is working properly).  malloc will give
: you a pointer just like NewPtr will.  If speed is important, then I can't
: answer the question for you.  I am using NewPtr in my apps, but I have put
: a wrapper around all of my memory allocation and free calls so that I can
: change the method of allocation easily.  (I can also track down annoying
: little memory problems this way too!).

malloc is a _lot_ faster than NewPtr() for allocating a lot of small
objects.  Most implementations of malloc simply call NewPtr() for
allocation of large objects.

--
Ken Prehoda, [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Demos)
Date: Thu, 18 May 1995 23:55:56 -0700
Organization: University of Utah

> This question is a good one.  I have talked with several people who have
> told me different things.  If speed is not important, and portability is, I
> would use malloc (assuming that it is working properly).  malloc will give
> you a pointer just like NewPtr will.  If speed is important, then I can't
> answer the question for you.  I am using NewPtr in my apps, but I have put
> a wrapper around all of my memory allocation and free calls so that I can
> change the method of allocation easily.  (I can also track down annoying
> little memory problems this way too!).

And the answer is simple:

If you want your program to be compilable on other platforms - use malloc,
otherwise - use NewPtr.

Demos

_____________________________________________________________________
Demos <[e-mail]>   |  IRC: #macdev  |  ftp://amug.org/pub/demos

+++++++++++++++++++++++++++

>From [e-mail] (Ken Prehoda)
Date: Fri, 19 May 1995 13:25:38 -0500
Organization: Univ of Wisc-Madison, Dept of Biochemistry

In article <[e-mail]>, [e-mail]
(Demos) wrote:

: > This question is a good one.  I have talked with several people who have
: > told me different things.  If speed is not important, and portability is, I
: > would use malloc (assuming that it is working properly).  malloc will give
: > you a pointer just like NewPtr will.  If speed is important, then I can't
: > answer the question for you.  I am using NewPtr in my apps, but I have put
: > a wrapper around all of my memory allocation and free calls so that I can
: > change the method of allocation easily.  (I can also track down annoying
: > little memory problems this way too!).
:
: And the answer is simple:
:
: If you want your program to be compilable on other platforms - use malloc,
: otherwise - use NewPtr.
:
: Demos
:
: _____________________________________________________________________
: Demos <[e-mail]>   |  IRC: #macdev  |  ftp://amug.org/pub/demos

No, it's not quite that simple.  If you program allocates a lot of small
objects, then allocate them using malloc.  Do you use operator new when
you use C++?  If so (and you are not overriding it), then you are using a
memory system similar to malloc (if not malloc itself).  In fact, if you
want to see just how slow NewPtr is, override operator new to just call
NewPtr.  If your program has many memory allocations at all, there will be
a very noticable difference.

--
Ken Prehoda, [e-mail]

+++++++++++++++++++++++++++

>From Narayanan Lakshmanan <[e-mail]>
Date: 22 May 1995 14:31:30 GMT
Organization: McDermott, Inc.

First, I have never had malloc return memory that is "in-use", thus I
suggest you look for a bug, perhaps in converting between
shorts/ints/longs, etc.  I have had that problem creep up when
programmers assumed too much, especially in unix/mac conversions.

Second, it is important to note that malloc had an upper limit beyond
which it could not allocate a single memory block.  I have not tested
this recently, so I cannot give you all the details.  However, when
pursuing a similar porting trial, I had to resort to NewPtr in some
cases.  Verify this by allocating a single block that is greater than
eight megabytes and see if it works for both malloc and NewPtr.

Third, you really should use NewHandle since it is much faster (weird,
but true!) for *larger* blocks.  I have had occassions to allocate
tremendous sized blocks, and the same code when rewritten to use
NewHandle performed nearly 30% faster.  Unfortunately, I have not gone
back to see if this happens on the new Power Macs and their "modern"
memory manager.

-- Nary



+++++++++++++++++++++++++++

>From [e-mail] (Robert Coie)
Date: 22 May 1995 18:24:55 GMT
Organization: Intrigue Corporation

In article <3pq782$[e-mail]>, Narayanan Lakshmanan
<[e-mail]> wrote:

: Third, you really should use NewHandle since it is much faster (weird,
: but true!) for *larger* blocks.  I have had occassions to allocate
: tremendous sized blocks, and the same code when rewritten to use
: NewHandle performed nearly 30% faster.  Unfortunately, I have not gone
: back to see if this happens on the new Power Macs and their "modern"
: memory manager.

It should.  The reason NewHandle is usually much faster than NewPtr is
that NewPtr always causes heap compaction, whereas NewHandle only does so
if the amount of memory requested is not available otherwise.

Robert Coie                              [e-mail]
Implementor, Intrigue Corporation     AppleLink: INTRIGUE

+++++++++++++++++++++++++++

>From j friend <[e-mail]>
Date: 23 May 1995 11:07:45 GMT
Organization: iii.net

[e-mail] (Scott Storkel) wrote:
>
> In general, I try to avoid malloc() simply because I don't know what
> it's going to do (or I do know, and I don't like it :-). I tend to use
> NewPtr() or write custom allocators that are more efficient than
> malloc()...


careful of this - if you are allocating lots of samll peices of memory
malloc may be MUCH more efficient than NewPtr because it will make fewer
calls to NewPtr (which is very expensive) to get large blocks which
it will then split up for you. In cases like this it can also prevent
some fragmentation.

jf

+++++++++++++++++++++++++++

>From [e-mail] (Scott Storkel)
Date: Tue, 23 May 1995 09:24:04 -0700
Organization: Devious Software & Consulting

In article <3psfmk$[e-mail]>, j friend <[e-mail]> wrote:

> [e-mail] (Scott Storkel) wrote:
> >
> > In general, I try to avoid malloc() simply because I don't know what
> > it's going to do (or I do know, and I don't like it :-). I tend to use
> > NewPtr() or write custom allocators that are more efficient than
> > malloc()...
>
> careful of this - if you are allocating lots of samll peices of memory
> malloc may be MUCH more efficient than NewPtr because it will make fewer
> calls to NewPtr (which is very expensive) to get large blocks which
> it will then split up for you. In cases like this it can also prevent
> some fragmentation.

Yes, I know. I've made the following observations about programs
I've seen:

        They allocate small numbers of randomly sized objects.
                                and
        They allocate large numbers of similarly sized objects.

For like-sized objects, these are typically the small ones, I use a custom
allocator which is *much* faster than malloc. For the randomly sized objects,
I call NewPtr. In general, if I allocate something enough that the performance
penalty for NewPtr would have an impact, I switch over to the custom allocator.

I've found this to be a pretty decent solution in most cases. It does require
more work than blindly calling NewPtr, but the results are generally better.


                                                                -- Scott

+++++++++++++++++++++++++++

>From Narayanan Lakshmanan <[e-mail]>
Date: 24 May 1995 12:59:33 GMT
Organization: McDermott, Inc.

>Any reason why you shouldn't allocate [a handle] first, then
>MoveHHi and lock it so it's at the very top?
>
You may not know the size of the data at the beginning of the program.

-- Nary



+++++++++++++++++++++++++++

>From [e-mail] (David Stone)
Date: Wed, 24 May 1995 13:53:18 GMT
Organization: University of Toronto Chemistry

In article <3pvajl$[e-mail]>, Narayanan Lakshmanan
<[e-mail]> wrote:
>
> >Any reason why you shouldn't allocate [a handle] first, then
> >MoveHHi and lock it so it's at the very top?
> >
> You may not know the size of the data at the beginning of the program.
>
> -- Nary

Actually, I do - and it's there from startup to quitting time.  (I use the
sizeof() function on my data type to do the allocation).  So I guess
there's
nothing wrong with this approach, then?

Dave Stone

+++++++++++++++++++++++++++

>From Duane Murphy <[e-mail]>
Date: 24 May 1995 14:32:34 GMT
Organization: Novell, Inc.

In article <[e-mail]> David Stone,
[e-mail] writes:
>Actually, I do - and it's there from startup to quitting time.  (I use the
>sizeof() function on my data type to do the allocation).  So I guess
>there's
>nothing wrong with this approach, then?
>

Normally, handles are used for data that is transient in nature or that
can float. Transient in the sense that you allocate it, use it for a
period of time and then deallocate it. The period of time is not as
interesting as how the data is accessed.

In my opinion, the floating nature is more interesting. If the data can
be allowed to move around in memory then you get the full benefit of
handles.

In your specific case where the data will be allocated at startup and be
locked for the duration, then there are two other approaches that you
might consider.

1. Use NewPtr. This puts the data LOW and out of the way. If you are
doing this at startup then it will be very low.

2. Use ReserveMem and NewHandle. Again this puts the memory low.

MoveHHI is appropriate if the time period for use of the data is
reasonably long _AND_ the data has to be locked (transient code resources
like XCMD's). Reasonably long is usually considered shorter than the
existance of the application ;-)

Be aware. Copland Memory Managment will make the use of pointers (NewPtr)
far more efficient. Handles will still be used (they do have there place)
but there are significant advantages to pointers in Copland.

Hope this helps,

 +-------------------------+--------------------------------------------+
 | Duane Murphy            | My opinions are mine, mine, and only mine; |
 | [e-mail] |      Except when they are also yours.      |
 +-------------------------+--------------------------------------------+

---------------------------

>From [e-mail] (Rodney Clayton)
Subject: newbie. How to get open file dialog box.
Date: 23 May 1995 14:56:40 GMT
Organization: University of Maryland, College Park

I have an application I ported from pc/dos. I would like to open
files for input and output and have the mac generate the dialog
box it usualy presents for most other applications. How do I go
about doing this? I am using semantec c++.
Thank's Rod

+++++++++++++++++++++++++++

>From [e-mail] (Lord of the Sith)
Date: Tue, 23 May 95 18:21:05 GMT
Organization: Drexel University, Dept. of Math. and Comp. Sci.

Rodney Clayton ([e-mail]) wrote:
: I have an application I ported from pc/dos. I would like to open
: files for input and output and have the mac generate the dialog
: box it usualy presents for most other applications. How do I go
: about doing this? I am using semantec c++.
: Thank's Rod

StandardGetFile();

I'm not sure of the parameter list right now, as I don't have books with me,
but one of them is a StandardFileReply *  which has as one it's members,
an FSSpec, which is the basic way to identify a file on the macintosh.

--
Matt Inger
[e-mail]
http://mcs.drexel.edu/~uminger/
"Remember when you were young?  You shone like the sun."

+++++++++++++++++++++++++++

>From [e-mail] (Rodney Clayton)
Date: 23 May 1995 20:14:44 GMT
Organization: University of Maryland, College Park

Lord of the Sith ([e-mail]) wrote:
: Rodney Clayton ([e-mail]) wrote:
: : I have an application I ported from pc/dos. I would like to open
: : files for input and output and have the mac generate the dialog
: : box it usualy presents for most other applications. How do I go
: : about doing this? I am using semantec c++.
: : Thank's Rod

: StandardGetFile();

: I'm not sure of the parameter list right now, as I don't have books with me,
: but one of them is a StandardFileReply *  which has as one it's members,
: an FSSpec, which is the basic way to identify a file on the macintosh.

: --
: Matt Inger
: [e-mail]
: http://mcs.drexel.edu/~uminger/
: "Remember when you were young?  You shone like the sun."
I was looking at the new INSIDE MACINTOSH books in the book store the
other day. Do you happen to know which one this stuff would be in?


+++++++++++++++++++++++++++

>From [e-mail] (Andrew)
Date: 24 May 1995 00:50:13 +0100
Organization: Adcode

In article <[e-mail]>, [e-mail]
(Lord of the Sith) wrote:

> Rodney Clayton ([e-mail]) wrote:
> : I would like to open files for input and output and have the mac generate
> : the dialog box it usualy presents for most other applications. How do I go
> : about doing this?

When you say 'usually', it should always do this. That's what makes the
mac the dog's bo**ocks. Mac programmers use the Mac toolbox where possible
to make this kind of thing happen and that's why all (well-behaved)
applications have a standard window (unlike windows apps).

Here's how to do it:

typedef OSType       SFTypeList[4] // unless your compiler has this type

OSErr GetTheFile (FSSpec &TheSpec)
{
StandardFileReply    Reply;    // holds the reply from dialog
OSType               TList     // The file types we are looking for
FileFilterProc       FFilter   // optional file filter
short                Ntps      // number of types in TList

                     FFilter = nil // see note on filter
                     Ntps = 1      // we'll look at one type (see note)
                     TList[0] = 'FFIL' // just look at type 1 fonts

                     StandardGetFile(FFilter,  Ntps, TList, &Reply);
                     if (Reply.sfGood) // ie., user did not cancel
                           {
                           TheSpec = Reply.sfFile;
                           return noErr;
                           }
                     else
                           return -43; // ie., file not found
}



Other things in Reply are sfType (Type of file), sfFlags (finder flags of
file), sfScript (Script of file - though just use zero)

Standard file is the standard way of getting a file. To get a folder is a
little more involved.

The parameters to standard file are as follows:

File filter function pointer: Use nil to ignore it but it allows you to
use your own procedure for working out whether or not each item in the
list is to be greyed out or selectable. It is useful if you are compiling
a list of files and do not want the ones already selected to be
re-selectable (if that's a word). Also useful for a 'get folder' routine -
mre of that later.

Number of file types - use zero to select from no files - sounds Irish but
is useful for selecting folders. To do this, e-mail me. It's a B'stard.
Use -1 to select from all file types.

Type list: An array of longs which hold the types you are searching for:
Fill out at least what you have specified in Number of File Types.

Pointer to reply structure - useful parameters shown above.

That's it really. The resulting reply can be used to operate on a file
using the System 7 FS traps, or split off the vRefNum, DirID and name from
the record and use the H traps instead.

Good luck with the app, Andrew.

--
Andrew Crane, Egham, Surrey, England <[e-mail]>

---------------------------

End of C.S.M.P. Digest
**********************